Let’s continue our journey with AWS OpenSearch Service. What we have is a small AWS OpenSearch Service cluster with three data nodes, used as a vector store for AWS Bedrock Knowledge Bases. Previous parts: AWS: Introduction to OpenSearch Service as a vector store AWS: Creating an OpenSearch Service cluster and configuring authentication and authorization Terraform:… Read More »
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… Read More »
In the previous post – AWS: VPC Flow Logs – logs to S3 and Grafana dashboard with Loki, we created a Grafana dashboard that displays NAT Gateway traffic usage statistics. What we were interested in there was which Kubernetes Pods use the most bytes, because it directly affects our AWS Costs. And everything appears… Read More »
Continuing the topic about AWS: VPC Flow Logs, NAT Gateways, and Kubernetes Pods – a detailed overview. There we analyzed how to work with VPC Flow Logs in general, and learned how we can get information about traffic to/from Kubernetes Pods. But there is one problem when using Flow Logs with CloudWatch Logs – the… Read More »
In continuation of the topic with Підготовка до зими 2024-2025: ДБЖ, інвертори, та акумулятори (in Ukrainian). Surprise – there’s even a Prometheus exporter for the EcoFlow – berezhinskiy/ecoflow_exporter! It looks really cool. I launched it, looked at it, and ran to write this post. It can be run in a couple of clicks with Docker… Read More »
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… Read More »
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 »
I didn’t plan this post at all as I thought I would do it quickly, but it didn’t work out quickly, and I need to dig a little deeper into this topic. So, what we are talking about: we have AWS Load Balancers, logs from which are collected to Grafana Loki, see. Grafana Loki: collecting… Read More »
We have an AWS Elastic Kubernetes Service cluster with Karpenter which is responsible for EC2 auto-scaling, see AWS: Getting started with Karpenter for autoscaling in EKS, and its installation with Helm. In general, there are no problems with it so far, but in any case we need to monitor it. For its monitoring, Karpenter provides… Read More »
Currently, we are able to collect our API Gateway logs from the CloudWatch Logs to Grafana Loki, see. Loki: collecting logs from CloudWatch Logs using Lambda Promtail. But in the process of migrating to Kubernetes, we have Application Load Balancers that can only write logs to S3, and we need to learn how to collect… Read More »