Always on watch.
Monitoring you run yourself.
Metrics, logs, traces and alerts in one place. A small agent on your Linux, macOS and Windows machines, a Helm chart for Kubernetes and a standard OpenTelemetry endpoint feed one server that stores everything, draws the dashboards and pages you when something breaks.
Add a Linux host with one command:
curl --proto '=https' --tlsv1.2 -fsSL https://app.meerkatlog.com/install.sh | MEERKAT_API_KEY=mk_... sudo -E sh
- One binarya static Go agent for Linux, macOS and Windows
- ~20 MBagent memory on a 1 GB VM, under 1 % CPU
- OTLPHTTP and gRPC from any OpenTelemetry SDK
- Push onlyno inbound ports on the machines you monitor
Infrastructure
Every host, with its processes and containers
The agent reports CPU, memory, disks, network, processes and Docker containers every 15 seconds. The host list shows who is busy and who is filling up; each host has a page of its own with its charts, logs, processes, traces and events.
- Linux, macOS (memory pressure and swap traffic, Apple Silicon or Intel) and Windows (services, Event Log)
- Signed apt and yum repositories, so
apt upgradekeeps the agent current - Buffers to disk while the server is unreachable
- Decommission a retired host and keep its history
Logs
Search every log line, or watch them arrive
Full-text and field search with facets, a histogram by level and live tail. Open a line to see all of its fields and filter on any of them with one click.
- journald, Docker, log files, the Windows Event Log, the macOS unified log, syslog and OTLP
- Pipelines parse lines at intake with regex, grok and built-in nginx/Apache parsers, remap or drop them and turn them into metrics
- Tokens, passwords and similar secrets are scrubbed before anything is stored
Traces and APM
See where a request spent its time
Rate, errors and duration for every service and endpoint, derived from your OpenTelemetry spans. Open a trace for its waterfall and jump to its logs; the service map shows who calls what, with databases and external calls.
- Error tracking: exceptions grouped into issues, with regressions
- Database query analytics by query shape, with N+1 detection
- Deployment markers from
service.version, with a before-and-after comparison - SLOs with burn-rate alerts
Monitors and alerting
Alerts that reach you, even with the app closed
Monitors are evaluated on the server. Built-in monitors cover hosts, disks, containers, checks, network devices, Kubernetes and vSphere; switch on the ones you need and add your own.
- Metric, APM, log, host down, process, disk space, disk-full forecast, new error and SLO burn-rate monitors
- Warn and alert thresholds, recovery thresholds, no-data handling and re-notify
- Mute a monitor, or hosts during maintenance; acknowledge an alert so its reminders stop while someone works on it
- E-mail, Slack, Telegram and webhooks
Dashboards and metrics
Dashboards that come ready, and ones you build
Built-in dashboards for hosts, the fleet, web traffic, the JVM and network devices. Clone one or start fresh with timeseries, query value, top list, table, log stream, text and SLO widgets and template variables.
- A metrics explorer with a query builder or raw MetricsQL
- Deployment markers on the charts, so a change in a line meets the release that caused it
- A DogStatsD listener on localhost for your own application metrics
Also built in
The rest of what a hosted monitoring service does, running on your own hardware.
-
Kubernetes
A Helm chart installs a node agent on every node (host, pod and container metrics, pod logs, volume usage) and a cluster agent for nodes, pods, deployments, daemonsets, statefulsets, Jobs, CronJobs, autoscalers and cluster events. Clusters, workloads and pods get their own pages: why a container fails (OOMKilled, CrashLoopBackOff), memory against its limit, node pressure, full volumes, failed Jobs, late CronJobs and autoscalers at their maximum, with monitor templates for each.
-
Real user monitoring
A small script in your web pages measures what visitors get: Web Vitals (LCP, INP, CLS) per page, sessions with a timeline of page views, API requests and JavaScript errors, with a link to the backend trace of each request that carried a trace header. JavaScript errors are grouped like backend errors, with built-in monitors for poor vitals and error spikes.
-
Synthetic checks
Ping, TCP (with an optional banner match, such as
SSH-), HTTP (status, keyword and JSON assertions, a degraded threshold, encrypted secret headers) and certificate checks (days to expiry, invalid chains), run by the agents you pick, so internal URLs and certificates work too. Heartbeat checks are a dead-man switch your backups and cron jobs ping. -
Network devices
The agent polls routers and switches over SNMP v2c and v3: interface traffic, errors and status, CPU, memory and uptime, with a MikroTik RouterOS profile for temperature, voltage and client counts. A syslog receiver (RFC 3164 and 5424) with a RouterOS parsing pipeline.
-
VMware vSphere and ESXi
The agent reads a vCenter or a standalone ESXi host through the vSphere API, read-only: ESXi hosts with CPU, memory, power draw, health and maintenance mode, virtual machines with power state, CPU ready, disk, network and snapshot age, datastores with free space, and vCenter alarms and events. Hosts that disconnect alert like any other host.
-
Integrations
systemd units and Windows services, WireGuard tunnels, nginx, PostgreSQL and Redis, plus the DogStatsD listener for your own metrics.
-
Organizations, users and roles
Separate organizations with their own hosts, telemetry, monitors and keys. Admin, editor and viewer roles, e-mail invites, two-factor authentication (TOTP), an audit log and a full data export. Self-hosted installs can switch on single sign-on (OIDC: Google, Microsoft Entra ID, Authentik, Keycloak) per organization; it is not yet available on app.meerkatlog.com.
-
API keys and HTTP API
Everything the UI does is in the HTTP API. Intake keys can be bound to host name patterns, read-only keys serve the API and the MCP server, write keys may make only the changes they are granted, and CI can report deployments with a deploy key.
-
Configuration as code
An organization's notification channels, synthetic checks, dashboards and monitors as one YAML document to keep in git.
meerkat configexports it, shows a plan of what would change and applies it. Channel credentials are never exported.
How it works
Agents and apps push over HTTPS with an API key, so monitored machines need no inbound firewall rules. One server receives, processes and stores the data and serves the app.
- Collect. The agent reads metrics every 15 seconds and tails logs; SDKs and the Collector export OTLP. Everything is batched, compressed and pushed to the intake host.
- Process. The server checks the API key, runs your log pipelines, scrubs secrets and derives request, error and latency series, service-map edges, error issues and query shapes from spans.
- Store. Metrics go to VictoriaMetrics, logs to VictoriaLogs, spans to VictoriaTraces, and hosts, dashboards, monitors and users to Postgres.
- Watch. Monitors evaluate on the server even when nobody has the app open, and notify your channels when a state changes.
OpenTelemetry
Bring your OpenTelemetry
Point any OpenTelemetry SDK at Meerkat with the standard environment variables. Traces, metrics and logs arrive with the service, version and environment you set; a new service.version shows up as a deployment marker on the charts. No Meerkat agent is needed inside your app.
- OTLP/HTTP with protobuf or JSON, optionally gzip
- OTLP/gRPC on port 443
- Java, Python, Node.js and Go examples in the docs
- Works through the OpenTelemetry Collector too
- Kubernetes attributes (
k8s.pod.name, …) link traces and errors to their pods
Environment for any OpenTelemetry SDK
export OTEL_SERVICE_NAME=checkout
export OTEL_RESOURCE_ATTRIBUTES=service.version=1.4.2,deployment.environment=prod
export OTEL_EXPORTER_OTLP_ENDPOINT=https://intake.meerkatlog.com/intake/v1/otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_HEADERS=Authorization=Bearer%20mk_your_key_here
export OTEL_TRACES_EXPORTER=otlp
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlpThe space in Bearer mk_… is written %20: header values in this variable are URL-encoded.
Self-hosted
Your data stays yours
Meerkat runs as a Docker Compose stack on a machine you control. Your metrics, logs and traces are stored there and nowhere else.
-
Small footprint
The server stack needs about 1 GB of free RAM. The agent uses about 20 MB of RAM and under 1 % CPU on a 1 GB VM by default, with a lean profile for the smallest machines.
-
Proven storage engines
VictoriaMetrics, VictoriaLogs, VictoriaTraces and Postgres behind Caddy with automatic Let's Encrypt certificates. Retention is configurable;
make backupdumps Postgres and snapshots the metric and log stores, and a nightly script sends encrypted archives of every store to another server. -
Secrets stay out
Tokens in URLs, authorization and cookie headers and similar secrets are removed at intake, before anything is written to disk. Add your own rules and try them with a dry run. Credentials you give Meerkat (Telegram and Slack tokens, webhook URLs) are encrypted at rest.
One load test, for scale: 200 simulated hosts sent data to the public intake for 15 minutes: about 1,650 intake requests per minute with no errors, while the server stayed at or below 16 MB of memory (VictoriaMetrics about 80 MB, VictoriaLogs about 120 MB), and the host list and a fleet-wide query answered in under 50 ms.
AI assistants
Ask your AI assistant
Meerkat includes a Model Context Protocol (MCP) server, so Claude, ChatGPT and other MCP clients can investigate your hosts, metrics, logs, traces, APM data, synthetic checks, monitors and events. Claude and ChatGPT connect as connectors: you sign in to Meerkat and pick the organization, with no key to paste. Other clients use a read key.
It is read-only by default: the assistant sees what you may see, with the same rate limits, and you can disconnect it at any time. If you opt in, an editor can let it mute hosts and monitors, acknowledge alerts, create and adjust monitors and synthetic checks, mark deployments and decommission hosts. Each change can be tried as a dry run first and is recorded in the audit log.
- Hosts and their metrics, MetricsQL, log search and facets
- Traces, service map, RED, errors and database queries
- Monitor status, checks, SLOs and recent events
- An incident investigation prompt that sticks to the evidence
Connect Claude Code (sign in in the browser)
claude mcp add --transport http meerkat \
https://app.meerkatlog.com/mcpIn claude.ai or ChatGPT, add the same address as a custom connector; use /mcp/write for the write tools. A read key in an Authorization header, or the standalone meerkat-mcp binary (stdio), works with any MCP client.
Always on watch.
A meerkat mob always keeps one member on sentry duty while the others work. That is the job.