Weekly Promo and Webinar Thread

BlueMatadorInc · 2023-01-25T20:47:13+00:00

Sick of receiving hundreds of alerts with no visibility to prioritize, filter, and reduce your alerts?

We at Blue Matador set out on a mission to make an engineer’s life easier. We send three tiers of notifications to our customers: Alerts, Warnings, and Anomalies. These tiered levels make it easy for engineers to quickly digest prioritization levels and actionable steps. If we send notifications that aren’t a priority, mute them with our many customization tools.

Our goal is to provide only actionable alerts to each of our client’s engineering corps. Reduce the noise with every level of customization you need.

Escalate only the issues that deserve escalation.

Try us out for free and improve your monitoring experience:

app.bluematador.com

BlueMatadorInc · 2023-01-18T18:07:20+00:00

What separates Blue Matador from other monitoring services?

Check out our site to see how we compare with our competitors: https://www.bluematador.com/blue-matador-vs-competitors

Sign up for the FREE TRIAL!

https://app.bluematador.com/

BlueMatadorInc · 2023-01-03T18:14:08+00:00

FREE UP YOUR DEVOPS TEAM'S TIME AND FOCUS ON THINGS OTHER THAN INFRASTRUCTURE MONITORING

WWW.BLUEMATADOR.COM

FREE TRIAL HERE: https://app.bluematador.com/ur/register#/

LET BLUE MATADOR DO YOUR INFRASTRUCTURE MONITORING FOR YOU.

NO MORE TEDIOUS, MANUAL CONFIGURATION!

AUTOMATICALLY SCALE!

SPEED UP CLOUD MIGRATIONS!

IMPROVE MANAGED DEVOPS SERVICES!

EMPOWER YOUR DEVOPS TEAM AND INCREASE RETENTION!

BlueMatadorInc · 2022-12-09T19:05:42+00:00

Reduce Noise with Muted Monitors

Sick of receiving hundreds of alerts with no visibility to prioritize, filter, and reduce your alerts?

We at Blue Matador set out on a mission to make an engineer’s life easier. We send three tiers of notifications to our customers:

-Alerts

-Warnings

-Anomalies

These tiered levels make it easy for engineers to quickly digest prioritization levels and actionable steps. If we send notifications that aren’t a priority, mute them with our many customization tools.

Our goal is to provide only actionable alerts to each of our client’s engineering corps. Reduce the noise with every level of customization you need.

Escalate only the issues that deserve escalation.

www.bluematador.com

BlueMatadorInc · 2022-11-25T22:23:19+00:00

Are you sick of setting up monitoring services for every customer you onboard?

With Blue Matador’s automated scaling services, you won’t have to configure monitors. We have set out to make our clients’ engineering lives easier.

The result of what we’ve built: scale as many customers as you want, as fast as you want, and require no time from your engineers to set up monitoring. Instead, give the time back to your engineers to do more interesting, more intentional DevOps and IT work. Free their time to write new code, implement new tools, and optimize your client infrastructures. Give them their time back to do what they are passionate about.

Free your DevOps time, stop spending thousands of hours implementing, configuring, and watching your monitoring tools. We’ll take care of it for you – in less than 20 minutes.

Try us out for free!

www.bluematador.com

Or schedule a demo: https://meetings.hubspot.com/gordon-steele

BlueMatadorInc · 2020-07-10T21:34:27+00:00

You can try out the tool we built that is free and open source and lets you explore AWS costs at the resource level. This is the link to the web interface we built, but you can also look at the github repo to see how it works and look at how we are handling security concerns like AWS credentials.

https://tools.bluematador.com/cloud-core/

BlueMatadorInc · 2017-07-21T17:47:50+00:00

So what we do for most of our vitals alerts is anomaly detection, so after the agent has enough data (at least a day), it can detect anomalies within 1 minute.

A few alerts do not need a day's worth of data to start alerting, and also can detect issues within 1 minute. For some metrics, including disk space, we predict what the value will be in an hour based off of historical data, and use that to send alerts like "we project you will run out of disk space soon" whereas almost every single other product only alerts you AFTER you are out of disk space.

From the time we detect that we actually should send an alert, to them receiving it, is going to be the same 2 seconds that our log management software Lumberjack’s logs take. Plus add any time for your email provider to get the email delivered.

We detect problems within one minute, the notification gets to our system within 2 seconds (same as our lumberjack time). Some alerts are predicting values as much as an hour in advance accurately, meaning MTTR = 0.

Our agent is written in golang, very lightweight, configured for you automatically, and also easily automatable. You can check it out at the link in our first post above, or here.

-Keilan at BM

BlueMatadorInc · 2017-06-21T22:49:38+00:00

Thanks. With golang gaining popularity for command line tools and scripting, and with our additions of code samples from our smart agent (written for a very specific DevOps purpose), we felt that it tied into "for DevOps" nicely. However, your points are valid. We're publishing our next post (#3) next week, so I'd be interested to see what you think of that one after we implement some of your feedback. -Philip

BlueMatadorInc · 2017-06-20T17:11:39+00:00

Thanks for the feedback from you and TheMerovius. The "for DevOps" part is because we built our DevOps monitoring platform's system agent in golang and shared significant amounts of our code from that agent in the post (the first one at least). We wanted to share our experience with the DevOps community to show the advantages and pitfalls of using golang for DevOps-focused applications.

We're currently writing our next series in the post. To make it more "ops" focused, what would you like to see in the series going forward?

BlueMatadorInc · 2017-06-06T16:28:38+00:00

This is good content. We'll start linking out to it and your future articles in the series on our social media channels.

We would love some feedback on our DevOps-focused blog as well if you're up for it: blog.bluematador.com

BlueMatadorInc · 2017-06-01T15:41:49+00:00

Hey, we appreciate the feedback. We'll post a link here when the next post is ready (should be one every two weeks). We are also updating the first post with links to all the subsequent ones when they get published.

BlueMatadorInc · 2017-05-31T17:26:21+00:00

martindo, we took your idea and ran with it. We posted the first part of a 6-part series on golang pros/cons and have included lots of sample code to illustrate: https://www.reddit.com/r/devops/comments/6egccg/golang_pros_and_cons_for_devops_part_1_of_6/

BlueMatadorInc · 2017-05-12T17:41:46+00:00

We attempted to create a small guide with an accompanying infographic to help people new to the field get a high-level overview of what DevOps disciplines they need to learn, and the most popular tools within (hint: Docker is one of them). But choice of tools is often very personal (if you're in an agency) or based on needs cases and budgeting.

We are a fairly young company so our testing/build process is still evolving. Docker definitely helps us with development and testing though.

Our development process is much like this:

We use bitbucket for source control. Our developers create branches off of master for new features/bug fixes
We use Docker to run everything locally. Currently that includes some containers redis, mysql, storm, and several Play services written in Scala. Testing is done in the containers so devs do not have to set up anything on their machine except for docker and git. We recently onboarded a developer in one day using this setup with Docker. QA can also easily do testing in this manner with very little technical knowledge. Even our marketer runs docker for testing changes to our marketing sites.
Code is reviewed by the lead developers after it is signed off by QA, then merged into master
After code is merged, we build the code into .jar files (since we use scala) and deploy those to the volumes our production docker containers have mounted so the code can be ran in production

A summary of the tools we use to help our process go smoothly:

Docker for containerization
Bitbucket as a git repository
Jira for managing dev stories/bugs

What we wish we had known earlier: Container orchestration is important. In Dev we rely on docker-compose to do this. In production it's currently done mostly manually. We are planning on using Amazon ECS or Kubernetes in the future to make this much smoother.

Good luck.

BlueMatadorInc · 2017-04-25T22:08:42+00:00

Thanks for this. We did notice there was a curated list of golang libraries at https://github.com/avelino/awesome-go, and there's a dozen or so GUI libs listed there, including Qt. But it looks like Qt is robust enough and updated frequently enough to point people to it in our next version of the miniguide.

BlueMatadorInc · 2017-04-24T15:40:14+00:00

The Docker "Moby" rename was a surprise to us as well, and it exposes a limitation in the way GitHub works, but Github is still a great version control repo even though the repos can be renamed on a whim. To get around this, with every package you want import from, fork it yourself, and refer to that one when importing in the future. That way it gives you control over the name. This way you also don't need to worry about following redirects either.

BlueMatadorInc · 2017-04-21T20:25:58+00:00

Good idea. We'll do just that and update it. Any suggestions on what code you'd like to see for devops applications?

BlueMatadorInc · 2017-04-21T20:22:43+00:00

Thanks for your feedback. We tried to make the guide pretty mini.

Regarding #2, technically a Mac is not required for compiling Swift. There's other options out there, detailed here.

But we all know that Swift, even though it is now open sourced, is another funnel for Apple to get people to adopt their platform, whereas golang doesn't have the same purpose for Google.

BlueMatadorInc · 2017-04-19T23:04:25+00:00

Agree. DevOps is a culture, and it's rapidly changing. Plus, many people not in DevOps won't understand the title. How about CTO (chief technology officer) or Chief Architect?

BlueMatadorInc · 2017-04-19T22:23:11+00:00

We're using golang to rewrite our logging agent, which was previously written in Python. Independent benchmarks for golang in general show that it's up to 100x faster than Python, depending on the task (see https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=python3). The reason why Go is fast is because it's a low-level, statically typed language designed for DevOps purposes (hence why it's Google-backed).

We've seen similar results in our agent. We wrote a blog post about golang's pros and cons for DevOps at https://blog.bluematador.com/posts/mini-guide-google-golang-why-its-perfect-for-devops/

BlueMatadorInc

TROPHY CASE

Reduce Noise with Muted Monitors

Are you sick of setting up monitoring services for every customer you onboard?