223 deterministic signatures read your logs the way an experienced on-call engineer would — matching the exact pattern of a known failure and naming it, instead of scoring "how anomalous" a line looks and leaving you to translate that into an action.
Most monitoring tools train a statistical model on your metrics and flag whatever looks unusual. That catches real problems — but it hands you a number, not an explanation. "Anomaly detected, confidence 0.87" still leaves the actual diagnosis to a human at 3am.
Kllyroo's signature engine works the other way. Instead of learning what's unusual, it's built from a library of what specific failures look like — the exact log line shape a MySQL connection-pool exhaustion produces, the specific pattern of a PHP-FPM worker being killed for running too long, the request signature of a webshell upload. When a signature matches, Kllyroo already knows the cause, because the pattern is the cause.
The same lightweight agent that reports server metrics also tails the logs relevant to detected services on that host — web server, app runtime, database, queue — no separate log shipper to install or maintain.
223 deterministic rules run against incoming lines. A match isn't a probability — it's a specific, named failure condition with a pre-written fix attached.
Each hit carries a confidence score and a category (web / app / database / queue / OS / security) so you can triage by severity and layer, not just by timestamp.
A line that doesn't match a known signature but looks worth a second look gets routed to the AI Chat layer for an LLM-generated explanation, instead of silently disappearing.
If a hit is part of a known cascade, causal correlation takes over from here and folds it into a single root-cause incident instead of a standalone alert.
A sample of the 223 — the full library spans 20+ stacks across these five layers.
| Layer | Signature | Detects | Typical fix |
|---|---|---|---|
| Web server | nginx_502_bad_gateway | Upstream refused or dropped the connection | Check upstream health before assuming it's nginx |
| Web server | nginx_worker_exhausted | Worker connections maxed under load | Raise worker_connections or add capacity |
| App runtime | phpfpm_request_terminated_slow | PHP-FPM killed a request for exceeding max execution time | Profile the slow endpoint; check for a blocking external call |
| App runtime | node_event_loop_blocked | Node's event loop stalled beyond threshold | Find the synchronous call blocking the loop |
| Database | mysql_too_many_connections | Connection pool exhausted | Raise max_connections or fix a connection leak |
| Database | postgres_replication_lag | Replica falling behind primary | Check replica I/O and long-running queries holding locks |
| Queue / cache | redis_oom_evicting_keys | Redis hit maxmemory and started evicting | Raise memory limit or fix an unbounded key pattern |
| Queue / cache | rabbitmq_queue_backing_up | Consumer rate falling behind publish rate | Scale consumers or find the stuck worker |
| OS / system | disk_space_critical | Filesystem nearing capacity | Clear logs/temp files or expand the volume |
| OS / system | oom_killer_invoked | Kernel killed a process for memory pressure | Identify which process spiked and why |
No score to interpret. A named signature, a plain-language explanation, and a fix — the same shape whether the layer is your web server, your database, or a security probe.
Offices in India and the US — reach out and we'll get back to you.