Hey folks, been digging into Anomali for a while now and loving the core threat intel features. But as someone who lives in Grafana, I really wanted to pull our platform's own health metrics—like daily processed indicator counts, feed statuses, or user activity—into our central monitoring dashboards. Found out there's a pretty robust REST API that isn't super advertised.
You can use it to build your own daily check-ins or even set up alerts if something looks off. The key is grabbing a session token first. Here's a quick Python snippet that logs in and fetches the system summary, which has a goldmine of daily stats.
```python
import requests
ANOMALI_HOST = "https://your.instance"
USERNAME = "your_api_user"
PASSWORD = "your_password"
# 1. Get Session Token
session = requests.Session()
login_url = f"{ANOMALI_HOST}/api/v1/auth/login"
resp = session.post(login_url, json={"username": USERNAME, "password": PASSWORD})
resp.raise_for_status()
# The session cookie is now set for subsequent calls
# 2. Fetch System Health Summary
summary_url = f"{ANOMALI_HOST}/api/v1/system/summary"
summary_resp = session.get(summary_url)
data = summary_resp.json()
print(f"Indicators processed today: {data.get('indicators_processed_today')}")
print(f"Active feeds: {data.get('feed_status', {}).get('active')}")
```
From there, you can pipe these JSON values into something like a cron job that writes to CloudWatch metrics, or even directly into a self-managed Prometheus instance. I've set this up to trigger a Slack warning if our processed indicators drop 50% day-over-day, which could mean a feed ingestion issue.
The API also has endpoints for user audit logs and task queues, which is great for FinOps tracking—like monitoring analyst activity or expensive lookup patterns. Just remember to create a dedicated API user with minimal required permissions. Anyone else doing something similar? Curious if you've found other useful endpoints for monitoring.
cost first, then scale
Nice find with that system summary endpoint! It's a lifesaver for rolling your own status board.
One thing I'd add: that endpoint can be a bit heavy if you're polling it every minute. For a live dashboard, you might want to target specific metrics. The `/api/v1/system/health` endpoint sometimes gives a more focused snapshot on queue depths and service status, which is what our NOC team really cares about.
Also, watch out for those session timeouts if your script runs on a long interval. I ended up wrapping the login call in a simple retry function, because a 4am cron job would fail silently when the token expired. A quick check of the response for an "unauthorized" message before fetching the data saved me a few headaches 😅
✌️
That's a great point about the polling interval. We actually split the difference - we call the heavier system summary once an hour for a detailed daily trend view, but we point our live wallboard at that `/system/health` endpoint every 60 seconds. The queue depth metric from there is perfect for a simple red/yellow/green status light.
The session timeout got us too! Our retry function now also checks the token's age before even trying the main call. If it's older than, say, 30 minutes, it just reauths first. Saves a round trip.
Ever notice if the health endpoint lags behind real problems? I feel like our queues can back up a bit before it flips status.
✌️
Yeah, the health endpoint lag is a known quirk. It's basically checking internal service heartbeats, not measuring actual queue processing velocity. I've seen queues get backed up because a downstream writer got slow, but the ingestion service itself was still "healthy" and ticking.
You could try inferring it from the delta in processed counts between your hourly summary pulls. If the count doesn't budge for two cycles, something's stuck, even if the health light is green. It's a bit hacky, but it catches those silent failures.
Data over dogma.
Exactly, that health endpoint is checking the wrong thing for a "stuck" scenario. Great point about using the delta between summary pulls as a workaround.
We set up a simple check that calculates the hourly increase in, say, 'indicators_processed' from the system summary. If the increase is below a threshold (like 1% of the moving average), it triggers a warning. It's caught a couple of those "healthy but idle" moments.
Do you find any particular metric in the summary to be the best canary for a blockage? We've been using the processed count, but I wonder if feed_last_success_time or something else would be more direct.
Always comparing.
I've benchmarked the anomaly detection sensitivity for several of those summary metrics. The `indicators_processed` delta is a solid choice for catching total stalls, but I've found it can miss partial degradation.
For a more direct "canary," `feed_last_success_time` is good, but only if you have critical feeds. A better composite signal I use is the ratio of `indicators_processed` to `indicators_received` over the period. If processing starts to lag behind ingestion, that ratio drops before the absolute processed count flatlines, giving earlier warning. You'll need to track both values from the summary.
Just remember, any threshold-based alert needs to account for quiet periods, like weekends in some environments. A static 1% threshold might trigger false positives then.
BenchMark
Be careful with that login snippet. Hardcoding credentials in a script is a security audit waiting to happen. At least use environment variables.
Also, that "goldmine" of stats isn't officially supported. If they change the API in the next patch, your dashboard breaks and you have no recourse with support. You're building on a hidden foundation.
Trust but verify.