CloudWatch capabilities for EBS monitoring

CloudWatch EBS Monitoring In our previous blog post we introduced CloudWatch envimation, CloudWatch Dashboard automation service, that allows you to generate dashboards for your EC2 instances easily. EBS volumes are a vital part of almost any infrastructure running on EC2 instances. Luckily, CloudWatch provides a number of metrics for EBS volumes. Since EBS volumes are a separate entity in AWS, when you create EC2 instance monitoring dashboards, the EBS metrics are not included by default.

Preventing DNS rebinding attacks using dnscrypt-proxy

Preventing DNS rebinding attacks using dnscrypt-proxy dns resolution is an attack vector that can be leveraged to bypass the Same-origin policy enforced by all browsers. The most insidious is DNS Rebinding, which this article very briefly covers before explaining a suggested mitigation based on dnscrypt-proxy ip blacklist capability. The initiation of the attack requires a webpage (or iframe ) containing malicious javascript that performs repeated requests to hostnames under a subdomain of the malicious script’s origin domain.

Easy AWS Monitoring using CloudWatch envimation

CloudWatch envimation In our previous blog post we talked about CloudWatch Dashboards and how to create them using either AWS console or AWS CLI. We also covered some of the difficulties arising when your infrastructure grows, and you want to get the most out of the available CloudWatch metrics. Let’s quickly wrap up pros and cons of using CloudWatch dashboards for data visualisation. PROs No external agents required, in fact, no configuration on your existing EC2 instances required Access to your data visualisation and monitoring within AWS, using IAM users and roles Native AWS Managed solution, so no need for external service management.

AWS-native monitoring using CloudWatch Dashboards

The Tool Cloud Cloud computing has introduced incredible flexibility in creating and managing servers. Every one of us can now bring up a machine of almost any size and power in a matter of minutes. One can host everything from a simple static blog page to flexible, scalable datacenter distributed across continents. There is one thing all of these use cases have in common though: you still need visibility of your infrastructure state.

Progress

Two sides of a coin The better you do the automation, the less the developer needs to think and learn to make it run. So, is the automation of tasks actually bringing us forward or the need to think less makes us simply less knowledgeable? Is the fact that we don’t spend time on daily tasks give us wider possibilities, or is it putting us away from the need to think?

nrpe server in golang

nrpe server In the first part we described how to use golang implementation of NRPE client to retrieve information from a running NRPE daemon. The library enables reusing of the existing nagios nrpe checks and integrating them into a golang monitoring-microservice. It requires NRPE daemon running on the server where the target service is running. The data collected by nrpe daemon provided by nagios plugins narrows down to server-specific parameters such as CPU/memory usage, DiskIO, network,server load and other system metrics.

golang client for nrpe

What is NRPE NRPE stands for Nagios Remote Plugin Executor. It’s a nagios plugin widely used to monitor remote Linux/Unix services or network devices. NRPE allows nagios to monitor any local resources like CPU, Memory, Load, etc by communicating with a NRPE daemon running on the remote server and listening to a port. The communication is done over TCP using the NRPE protocol. Here is a nicely put explanation of the protocol.

gomongo part 2

golang microservice on mongo inside docker Environment used in this example: host: MacOS 10.10.5 coreOS: alpha (1000.0.0) Docker: version 1.10.3 docker-compose: version 1.6.2 End-to-end example: part2 Simple microservice written in golang, reading data from mongodb, packed into docker and linked used docker-compose. In this series we will be building a very simple http REST interface on top of a small, filled with geo-data mongodb. You will see how to start thinking about things like automated deployment and continuous delivery in early stages of development.

docker networking part 2

Docker networking Environment used in this example: host: MacOS 10.10.5 coreOS: alpha (1000.0.0) Docker: version 1.10.3 part2 Hello fellow docker enthusiast! I am going to lay down some of the networking principals of docker here, with some concrete examples and detailed steps on how to see it all yourself. Throughout the article I am going to use coreOS-on-vagrant as my host for docker demo. The reason I am choosing coreOS here, is that it comes with docker pre-installed, it takes 5 minutes to start it up and it all makes it a perfect playground for docker.

docker networking part 1

Docker networking Environment used in this example: host: MacOS 10.10.5 coreOS: alpha (1000.0.0) Docker: version 1.10.3 part1 Hello fellow docker enthusiast! I am going to lay down some of the networking principals of docker here, with some concrete examples and detailed steps on how to see it all yourself. Throughout the article I am going to use coreOS-on-vagrant as my host for docker demo. The reason I am choosing coreOS here, is that it comes with docker pre-installed, it takes 5 minutes to start it up and it all makes it a perfect playground for docker.

gomongo part 1

golang microservice on mongo in docker Environment used in this example: host: MacOS 10.10.5 coreOS: alpha (1000.0.0) Docker: version 1.10.3 docker-compose: version 1.6.2 End-to-end example: part1 of simple microservice written in golang, reading data from mongodb, packed into docker and linked used docker-compose. In this series we will be building a very simple http REST interface on top of a small, filled with geo-data mongodb. You will see how to start thinking about things like automated deployment and continuous delivery in early stages of development.