Sort log lines and alerts
Which service, how bad, and whether customers feel it, on every alert, so on-call sees the one that matters.
Try it on this example
Log line or alert text
- Which of our services is failing or affected in this log line?Payments95%
- How severe is the problem this log line describes?Outage100%
- Does the problem in this log line reach customers or merchants?Yes98%
- What kind of failure does this log line show?Timeout or no response100%
- Does the log line say the problem has recovered or a retry succeeded?No95%
- Does the log line contain a password, key, token or a customer's personal data?No85%
These are real answers stored from one run on this example.
The prism behind it
Sort log lines and alerts
Fields
- Log line or alert text
Context
The lines come from the error logs and alert history of Parcelry, an online shop platform, exported for the weekly on-call review. Each line is one log entry or one alert message as the monitoring tool wrote it. The answers sort a week of lines by service and severity, so the review starts with the ones that hurt customers, and flag lines that leak secrets or personal data. Rates, counts across lines and whether an alert is new are worked out in code from the alert history. Our services: - Payments: payments-api, ledger-svc, payouts-worker, the card provider connection. - Auth: auth-svc, login, SSO, session and token handling. - Search: search-api, indexer, product search. - Orders: orders-api, checkout-ui, cart, stock reservations. - Notifications: email, SMS and push senders, webhooks to merchants. - Platform: databases, queues, caches, Kubernetes nodes, load balancers, DNS and certificates.
Questions
Which of our services is failing or affected in this log line? Choice
Use the service list in the context. When one service reports a failure in another that it calls, pick the service that failed. Pick one option.
How severe is the problem this log line describes? Scale
Go by what the line says happened, not by its log level alone: an ERROR line about one retried request can be a warning, and an INFO line can report an outage.
Does the problem in this log line reach customers or merchants? Yes / No
Count failed checkouts, logins, searches, payments, orders or messages that a shopper or merchant would see. A failure in a background job with no sign it reached anyone does not count. Yes: The line shows customers or merchants are affected. No: The line shows no effect on customers or merchants.
What kind of failure does this log line show? Choice
Go by what the line says went wrong. When a timeout comes from a dependency, it is still a timeout. Pick one option.
Does the log line say the problem has recovered or a retry succeeded? Yes / No
Count words such as resolved, recovered, back to normal, healthy again or retry succeeded. Yes: The line says the problem has cleared. No: The line says the problem is ongoing, or does not say.
Does the log line contain a password, key, token or a customer's personal data? Yes / No
Count a password, an API key, a bearer or session token, a card number, or a name, email address, phone number or postal address of a customer. Order numbers, request IDs and masked values such as "tok_****" do not count. Yes: The line contains at least one such value. No: The line contains no such value.
Lens columns
service, service_probability, severity, severity_average, customer_facing, customer_facing_probability, failure_type, failure_type_probability, recovered, recovered_probability, leaks_secret_or_personal_data, leaks_secret_or_personal_data_probability
Run it on your own text
Add this prism in the app, change any question, and test it on a file of your own.