3 ms·

From recent experience, I'm thinking logs need to be written for AI. Over the last few months, I've had a couple of issues where I took a bunch of logs from a

by keithnz 7mo ago

From recent experience, I'm thinking logs need to be written for AI. Over the last few months, I've had a couple of issues where I took a bunch of logs from a bunch of interacting programs, pointed the AI at the logs and the source code and it's been really effective and finding the problems, often seeing patterns that would have been really hard for me to spot in all the noise.

mjevans 7mo ago
The log needs to document, at least in broad steps and critical details, what the next operation is and what key parameters were provided to it. A human, or an 'agent' can use those to figure out why said next step might have gone wrong.
- ziml77 7mo ago
  This is the way I like to do it. I know bloating the logs too much can be a problem, but it's even worse if you're lacking information to reconstruct what happened when there ends up being a problem. And only providing that detail when there's an error isn't enough. What if the issue never triggered an error in the application and it was only caught later on either by a person seeing something was off or by an error a downstream system? Also it's helpful to log before operations rather than after because if a step gets stuck it's possible to know what it's stuck on.
Spooky23 7mo ago
We have a magic button in servicenow that lets the L1 agent kick off a job that pulls telemetry from a user device and do an overall health check of the device. That input identifies the issue like 80% of the time if it’s a device issue. It either gets resolved quicker by the L2 guy or dispatched to the third party hardware fix it guy or sent to some speciality L3 team. Resolution time is down like 60%. My next goal is to assess disk and battery health in laptops and proactively replace if they hit whatever threshold we can push the vendors to accept. That could eliminate something like 30% of device related issues, which has a super high value.

by keithnz 7mo ago

mjevans 7mo ago

The log needs to document, at least in broad steps and critical details, what the next operation is and what key parameters were provided to it. A human, or an 'agent' can use those to figure out why said next step might have gone wrong.

ziml77 7mo ago
This is the way I like to do it. I know bloating the logs too much can be a problem, but it's even worse if you're lacking information to reconstruct what happened when there ends up being a problem. And only providing that detail when there's an error isn't enough. What if the issue never triggered an error in the application and it was only caught later on either by a person seeing something was off or by an error a downstream system? Also it's helpful to log before operations rather than after because if a step gets stuck it's possible to know what it's stuck on.

Spooky23 7mo ago

We have a magic button in servicenow that lets the L1 agent kick off a job that pulls telemetry from a user device and do an overall health check of the device. That input identifies the issue like 80% of the time if it’s a device issue. It either gets resolved quicker by the L2 guy or dispatched to the third party hardware fix it guy or sent to some speciality L3 team. Resolution time is down like 60%. My next goal is to assess disk and battery health in laptops and proactively replace if they hit whatever threshold we can push the vendors to accept. That could eliminate something like 30% of device related issues, which has a super high value.