Got a new task to monitor costs on OpenAI – to see how much each project spends per day, and send alerts to Slack if costs exceed a set threshold. I tried several existing exporters for the OpenAI API, but none provided cost metrics per project – so we’ll build one ourselves. To create the… Read More: Golang: creating OpenAI Exporter for VictoriaMetrics0 (0) »
One day I received one of the default VictoriaMetrics alerts that are generated during the deployment of the Helm chart victoria-metrics-k8s-stack: I thought about writing a short post like “What is Churn Rate and how to fix it,” but in the end, I ended up diving deep into how VictoriaMetrics works with data in general… Read More: VictoriaMetrics: Churn Rate, High cardinality, metrics, and IndexDB0 (0) »
We use two systems for collecting logs in the project: Grafana Loki and VictoriaLogs, to which Promtail simultaneously writes all collected logs. We cannot get rid of Loki: although developers have long since switched to VictoriaLogs, some alerts are still created from metrics generated by Loki, so it is still present in the system. And… Read More: VictoriaLogs: “rate limit exceeded” and monitoring ingested logs0 (0) »
I have already mentioned the EXPLAIN feature in the PostgreSQL: AWS RDS Performance and monitoring blog post, but this is such an interesting and useful thing that it’s worth talking about it separately. In addition, AWS RDS for PostgreSQL has the ability to enable Execution Plans logging with EXPLAIN, which is also useful for monitoring… Read More: PostgreSQL: using EXPLAIN and setting up “auto_explain” in AWS RDS0… »
We are migrating our Backend API from DynamoDB to AWS RDS PostgreSQL, and several times RDS crashed. Actually, given that we took db.t3.small with two vCPUs and two gigabytes of memory to save money, it was quite expected, but I wondered why everything was crashing. A few days later, I started to debug the issue,… Read More: PostgreSQL: AWS RDS Performance and monitoring0 (0) »
We continue the migration from Grafana Loki to VictoriaLogs, and the next task is to transfer Recording Rules from Loki to VictoriaLogs and update the alerts. Recording Rules and integration with VMAlert were brought to VictoriaLogs relatively recently, and I haven’t tested this scheme yet. Therefore, we will first do everything by hand to see… Read More: VictoriaLogs: creating Recording Rules with VMAlert0 (0) »
So, we’re back to the topic of AWS VPC Flow Logs, VictoriaLogs, and the Grafana dashboard. In the post VictoriaLogs: a Grafana dashboard for AWS VPC Flow Logs – migrating from Grafana Loki, we created a cool dashboard to display various statistics on AWS NAT Gateway traffic. But there is a small drawback: all the… Read More: Vector.dev: introduction, AWS S3 logs, and integration with VictoriaLogs0 (0) »
VictoriaLogs is a relatively new system for collecting and analyzing logs, similar to Grafana Loki, but – like VictoriaMetrics compared to vanilla Prometheus – less demanding on CPU/Memory resources. Personally, I’ve been using Grafana Loki for about 5 years, but sometimes I have concerns about it – both in terms of documentation and the overall… Read More: VictoriaLogs: an overview, run in Kubernetes, LogsQL, and Grafana0 (0) »
In Kubernetes, in addition to metrics and logs from containers, we can get information about the operation of components using Kubernetes Events. Events usually store information about the status of Pods (creation, evict, kill, ready or not-ready status of pods), WorkerNodes (status of servers), Kubernetes Scheduler (inability to start a pod, etc.). Kubernetes Events types… Read More: Kubernetes: monitoring Events with kubectl and Grafana Loki0 (0) »
Tracing allows you to track requests between components, that is, for example, when using AWS and Kubernetes we can trace the entire path of a request from AWS Load Balancer to Kubernetes Pod and to DynamoDB or RDS. This helps us both to track performance issues – where and which requests are taking a long… Read More: Kubernetes: tracing requests with AWS X-Ray, and Grafana data source0… »