Centralized logging and observability stack for our servers
Employer
Igor
Project parameters
Type of cooperationOne-time project
SectionAdministration
Prepaymentwithout prepayment
Payment methodsCash, Bank transfer
Acceptance of requestsfrom today, 05:35 until Sep 14, 2026
Project description
Right now we are essentially blind to what happens in production. Logs are scattered across a dozen servers, each application writes to its own files in its own format, and when something breaks we log in over SSH and grep through gigabytes by hand. By the time we notice a problem a customer has usually already reported it. We want to fix this properly: build a centralized logging and observability stack that pulls logs and metrics from every server and every service into a single searchable place, so the whole team can see what is going on without touching the machines.
The target setup is an ELK or OpenSearch cluster for logs together with Grafana for metrics and visualization. We expect you to deploy log shippers on our hosts, normalize and parse the incoming streams into structured fields, and design dashboards that make sense for both engineers and management. On top of that we need alerting: notify us when the error rate spikes, when request latency crosses a threshold, when a service stops sending data, or when disk and memory run low. Alerts should reach us through the channels we already use, with sensible thresholds so we are not drowned in noise.
Retention and cost matter to us. Please set up index lifecycle and rollover so recent data stays hot and searchable while older logs are rolled off or archived on a defined schedule. Document the architecture, the parsing rules, and how to add a new service to the pipeline, so our own team can maintain and extend it afterwards. If you have run this kind of stack in production before, tell us how you would size it for our volume.
— Log collection from Linux servers and containerized apps
— Structured parsing, indexing and full retention policy
— Grafana dashboards for errors, latency and resource usage
— Alerting on error spikes, latency and silent services
The target setup is an ELK or OpenSearch cluster for logs together with Grafana for metrics and visualization. We expect you to deploy log shippers on our hosts, normalize and parse the incoming streams into structured fields, and design dashboards that make sense for both engineers and management. On top of that we need alerting: notify us when the error rate spikes, when request latency crosses a threshold, when a service stops sending data, or when disk and memory run low. Alerts should reach us through the channels we already use, with sensible thresholds so we are not drowned in noise.
Retention and cost matter to us. Please set up index lifecycle and rollover so recent data stays hot and searchable while older logs are rolled off or archived on a defined schedule. Document the architecture, the parsing rules, and how to add a new service to the pipeline, so our own team can maintain and extend it afterwards. If you have run this kind of stack in production before, tell us how you would size it for our volume.
— Log collection from Linux servers and containerized apps
— Structured parsing, indexing and full retention policy
— Grafana dashboards for errors, latency and resource usage
— Alerting on error spikes, latency and silent services
