If you’re already using Elastic Observability, you know the major advantage of bringing your monitoring data together into a unified view. When you add StackState on top of Elastic’s strong data foundation, you enrich it with a deep, real-time view.

Anthony Evans from StackState wrote this blog post. Anthony is a Solutions Engineer with StackState and a lifelong technologist. He has spent the last 15 years helping companies advance their software delivery capabilities while maintaining reliability, working extensively to support customers in the SaaS, AI, and Service Management landscapes.
Meeting the goal of delivering great performance and reliability in the face of our ever-changing, increasingly autonomous IT environments is fundamentally challenged by a data problem. Sure, there’s lots of it - logs, metrics, and APM traces - but it is exceedingly hard to extract actionable information when there are so many fast moving parts.
If you’re already using Elastic Observability, you know the major advantage of bringing your monitoring data together into one unified view. When you add StackState on top of Elastic’s strong data foundation, you enrich it with a deep, real-time view of topology and its constant changes. This is the contextual layer that is key for pinpointing the root cause of most performance problems and preventing them from occurring in the future. Read on to see the magic that happens when Elastic and StackState team-up.
Before the relationships between components became so complex, you could practically pinpoint a problem off the top of your head. If your shopping cart service wasn't working, you could point to a set of particular machines, physically log into them, and figure it out. Everything sat in one place, so it was simple. You could build dashboards apriori and they would provide great benefit during times of need.
Nowadays, your systems are continuously changing. If you get an error or alert that suddenly says, “I can not put stuff in my shopping basket anymore,” there could be a thousand reasons why. And even though you have a lot of data, it's overwhelming rather than helpful because (1) you're drowning in data and (2) you miss the context to act on it. It becomes very difficult - if not impossible - to manually find a root cause in this ever-changing, super complex environment. This is why you need the ability to automate root cause analysis.
<h2 dir="ltr">The importance of a time-traveling topology for root cause analysis</h2>Without a <a href="https://www.stackstate.com/blog/using-a-time-traveling-topology-to-create-escalation-graphs">time-traveling topology</a> however, root cause analysis is a lot like searching for a needle in a haystack. When a problem occurs, what you can do is work on a set of hypotheses and start checking dozens of different logs from dozens of different services. But that is a lot of work.
Instead, a good place to start is by asking, “What changed?”. For example, your cloud provider’s autoscaler spun up a new machine, a number of Kubernetes pods started to run on that machine as part of a set of services, and all of that coincided with a configuration change in a Kubernetes deployment. Let’s say you take all that change data and you stick it into Elasticsearch. Elasticsearch ingests, stores and analyzes all this data at scale. Then, Elastic Observability puts all that monitoring data into one unified view. You now have a powerful observability data foundation, but there’s one thing missing: you need to know how your data relates to each other.
<img src="https://lh4.googleusercontent.com/1NO9KLzRCG0BH5i7h09LAARYK9lqqLMNM2jr9IXk_TUkNTxl7dhzplQh6m9pxD8JMe4YNDUVjUJberU-Oteo2IAWnNAsXKY_Z4o69Kpfwy6WI_7kGYZlZEAVdGVxHWcJBI_MITSp=s0" width="624" height="344">
<figcaption>StackState screenshot showing how impact on the sock-shop Kubernetes namespace is caused by underlying dependencies, how alerts are clustered and which changes are probable causes
</figcaption><h2 dir="ltr">Tracking changes and dependencies</h2>That is exactly where the magic happens between Elastic and StackState. The tracked changes in StackState’s time traveling topology make it trivial to see the correlation between the change caused by the auto scaler and the change in Kubernetes deployment, and the causality between the two. You now know that this machine is part of a production Kubernetes cluster running in a certain cloud region. Kubernetes started running pods that all belong to a single deployment - it’s the net around all those things.
Sounds good, doesn’t it? StackState pinpoints the root cause of change-induced problems in highly dynamic environments, and Elastic Observability then gives you all the relevant in-depth details. However, there’s one more challenge: doing this typically requires a lot of data, especially if you want to keep this data around for several years to build enough context for Elastic features like machine learning to work on and produce most accurate results. That data has gravity and there is a lot of physics involved.
<h2 dir="ltr">No need to copy Elastic Observability data to StackState</h2>Luckily, there’s a solution for that: StackState can work with the existing data on Elastic without requiring you to copy it over to StackState. This is important because Elastic allows you to perform savvy-based decisions regarding data storage by providing the concept of data tiers: a hybrid storage approach where hot data can be kept on high-performance disks, and warm data can be kept on lower-cost performance disks. Most recently, Elastic also allows you to <a href="https://www.elastic.co/blog/introducing-elasticsearch-frozen-tier-searchbox-on-s3">tune your data compute and storage utilization</a> using the frozen tier. This means you can decouple storage from compute and store years of data without going crazy in terms of infrastructure costs. StackState will only store the time traveling topology and will leverage Elastic data as if it were all part of the same platform. Retention configurations of StackState’s time traveling topology are also entirely decoupled from Elastic’s observability data.
So, if a customer says, “I have a few exabytes of log data of my cloud native applications in Elastic Cloud”, then what StackState will say is, “Okay, that's fine. Keep all of that.” Because when you are investigating an issue, you can use StackState’s time traveling topology to do so. Also, when you need to access the relevant metrics or logs to further investigate the issue, you can do so through StackState by analyzing the data that comes directly from Elastic.
But that’s not all: StackState can use existing data in Elasticsearch to extend the topology in StackState. All you have to do is let StackState read the topological data from Elasticsearch and it will automatically build a time-traveling topology. Consider how much more value you can get out of beats such as osquery and packetbeat sitting in your Elasticsearch cluster!
Running side by side, customers would have all the benefits and capabilities of Elastic’s powerful observability infrastructure with the added bonus of StackState’s time-traveling topology that says, “Ding! Ding! Ding! Here’s where your problem happened!”
<img src="https://lh5.googleusercontent.com/Kb3RxP5OfJcF1Ikgu1po4RYQ7t7qkK7jA9sEcUBnbYUYWjlekW8q-nScYYGxpjn8b56dmzKQCXpxtHbXGxzalb9oFRPgDUAbmP9-UBUIT0lc9j1IVjsxhQVMBwSxSkPbnfyCZ6zS=s0" width="624" height="341">
<figcaption>Screenshot of StackState showing ElasticSearch data in an auto generated view for a selection of topological components
</figcaption><h2 dir="ltr">To conclude, here’s where the magic happens between Elastic and StackState:</h2><ul>
	<li dir="ltr" aria-level="1">Ingest all your telemetry data into Elastic and use its very awesome cloud infrastructure.</li>
	<li dir="ltr" aria-level="1">Use StackState’s real-time discovery to build a topology, track all changes and contextualize Elastic Observability data.</li>
	<li dir="ltr" aria-level="1">Quickly pin-point, dive-deep, resolve— and ultimately prevent — problems altogether in dynamic cloud-native environments.</li>
</ul><h2>Community meetup</h2>Pretty neat, right? If you want to understand a bit more about how StackState can help you to quickly identify the root cause of service infrastructure issues, <a href="https://community.elastic.co/events/details/elastic-emea-virtual-presents-identifying-service-infrastructure-problems-in-an-eye-blink-with-stackstate-and-elastic/">join us on Sep 23</a>, when Anthony Evans, Solutions Engineer from StackState, will demonstrate the product live and answer any questions you may have.
<h2>Next steps</h2>Want to learn more? <a href="https://www.stackstate.com/schedule-a-demo">Reach out to StackState directly</a> to schedule a personal demo. Or, if you want to see more of how StackState works on your own, <a href="https://play.stackstate.com/">explore the hands-on playground</a>, or <a href="https://www.stackstate.com/trial-sign-up/">request a free trial</a> of your own. We’re looking forward to helping you make the most out of your data.

blog-banner-charts-packages.png

blog-thumb-charts-packages.png

No more searching for a needle in a haystack: A world where Elastic & StackState team up

Everything that Elastic builds is free and open and we love to receive contributions from the community. Not sure how to contribute or get started? We’ll share a few tips on how to contribute with code.

We created the <a href="https://www.elastic.co/community/contributor">Elastic Contributor Program</a> to encourage knowledge sharing in our community and to recognize and reward the hard work of our awesome contributors. There are six different contribution types accepted in the program: <a href="https://www.elastic.co/blog/elastic-contributor-program-how-to-organize-an-elastic-meetup">event organization</a>, <a href="https://www.elastic.co/blog/elastic-contributor-program-tips-for-speaking-at-an-event">presentation</a>, <a href="https://www.elastic.co/blog/elastic-contributor-program-tips-for-creating-written-content">written content</a>, <a href="https://www.elastic.co/blog/elastic-contributor-program-how-to-create-a-video-tutorial">video</a>, translation, and code.
In this blog post, we’ll cover how to contribute code in the many free and open projects that Elastic maintains.
<h2>Getting started</h2>First, let’s clarify what qualifies as code content for the Elastic Contributor Program. In order to receive points, the code must be submitted to one of the projects that are available in <a href="https://github.com/elastic">Elastic’s organization on GitHub</a> and be approved by one the project maintainers. This means that the provided code ultimately aims to improve technologies provided by Elastic. While we appreciate any type of code contribution, only the ones whose purpose is to improve Elastic technologies will be accepted. Make sure to check out the <a href="https://www.elastic.co/community/contributor/rules">Elastic Contributor Program rules page</a> for the full rules.
But what if you build code that doesn’t improve an Elastic technology, but instead is used to demo a certain feature or concept? While you won’t be able to submit your work as a code contribution to the Elastic Contributor Program, you could submit as a blog post, video, or as a presentation that demonstrates your code and teaches people how to use it.
<h2>Which project should I contribute to?</h2>A quick peek at the repositories listed on Elastic’s organization on GitHub will show that there are many projects available. While this is exciting in theory it also poses an important question that you should ask: which project you should contribute to?
Likely, you will contribute to the project that is behind the stack that you use in your work. Most code contributions start from users that are already working with a specific technology and they feel so comfortable enough with them to the point where they also feel comfortable in improving them. Most contributions are actually based on scenarios that users have worked with so frequently that they have discovered better ways to solve the problem and want to make sure their solution belongs to the project.
When you start thinking about how to contribute to the project, you may realize that choosing to contribute based solely on the fact that you use it might not be enough. You’ll also need to evaluate whether you have mastered all the tools needed to contribute.
By tools we mean the technologies that are needed to write, compile, test, and build the code on the project. As an example, let’s suppose that you are a Java developer that is comfortable with the tooling in Java to build applications. In this case, contributing code to the <a href="https://github.com/elastic/beats">Beats project</a> may be a little hard because the project is based on Go and the tooling will be different. For this reason we recommend that you pick projects written in a programming language that you’re comfortable with.
In GitHub you can filter projects based on programming language. Go to Elastic's <a href="https://github.com/elastic">GitHub organization</a> and filter the public repositories for your programming language of choice. For example, if you are interested in Java then you can search for all projects that are public and based on Java like this:
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt11b655515aa198cc/5feb456ba7955d1a6a891869/blog-community-contribute-code.png" data-sys-asset-uid="blt11b655515aa198cc" alt="" style="display: block; margin: auto; width:700px;">
Alternatively, you can execute the same search in the browser by using <a href="https://github.com/elastic?q=&type=public&language=java">this query</a>.
<h2>Making an impactful contribution</h2>Whether fixing bugs or building new features, developers love when their efforts positively change the project — which is why they want to know how to make their contributions impactful. Working on the core of a given project may be tempting, but there are other ways to make an impact as well. Working on code that is consumed by end users is a good example.
Any part of the code that is exposed to users, such as APIs, SDKs, and plugins will generate more issues because there is no way to anticipate all the possible scenarios that developers may come up with. For this reason, focusing on code that developers interact with during their implementations makes the contribution particularly more useful for the project, as well as for the maintainers.
Building reusable extensions is another way to make an impact. If you identify a particular problem that many developers struggle with and build a reusable solution for it, that will certainly stand out. <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.10/modules-plugins.html">Elasticsearch</a> and <a href="https://github.com/logstash-plugins">Logstash</a> are good examples of projects where you can explore things like this because they both use plugins.
Lastly, give some love to security issues. At Elastic we take security very seriously and we want to make sure that our software is as secure as possible. If you find a vulnerability in any of our software don’t think twice — share your findings and help us to build a fix for it. You can find more information on how to submit security issues <a href="https://www.elastic.co/community/security">here</a>.
<h2>Ready, set, code!</h2>Let’s discuss a pragmatic view of the process. First, make sure to carefully read the licensing details of the selected project. This may seem unnecessary since most of us just want to contribute and we feel comfortable with whatever license the project is using. But this is important because your code may introduce dependencies into the project and these dependencies may not follow the same licensing rules.
This will force you to revisit not only your code, but also the way you solve a particular problem. Contributions can be rejected because the dependencies are not inline with the project’s license.
In order to contribute code, developers usually fork a repository, create a branch that will contain the code for the contribution, and then file a PR (Pull Request) in the project. We recommend that you resist the temptation of building a PR right off the bat. Instead, create an issue in the project to discuss the need of the PR.
This is important because some PRs may not be well received. Sometimes the PR may fix a feature that will be soon deprecated and the maintainers don’t want to encourage the usage of that feature. Maybe the new feature that you are coming up with is on the roadmap already. Or maybe the PR can’t be accepted because the code that you are trying to change is blocked by some other features that need to be addressed first, or it may impact other modules that require you to provide code. The point here is that before you spend energy in building a PR, you first discuss the need for it with the project maintainers. This will save you from the possible disappointment of getting your PR rejected.
If, after discussing the issue, your PR is welcomed by the project maintainers then go ahead and do your best while writing the code content. This means writing clear, simple, and maintainable code, using the right data structures and algorithms to ensure execution efficiency. Whenever necessary, provide enough comments, mind any security vulnerabilities that either your code or the dependencies may introduce, and lastly provide some testing code given the guidelines of the project.
Keep in mind that every project usually has a set of guidelines that you’ll need to abide by when contributing code. For example, the Elasticsearch project guidelines for contributing can be found in a file called <a href="https://github.com/elastic/elasticsearch/blob/master/CONTRIBUTING.md">CONTRIBUTING</a> that is available in the project’s repository. Likewise, guidelines for testing are also available in the <a href="https://github.com/elastic/elasticsearch/blob/master/TESTING.asciidoc">TESTING</a> file.
Once your code is ready create a PR in the project, and ask the maintainers to review it. If you need help handling PRs, our blog <a href="https://www.elastic.co/blog/how-we-handle-pull-requests-at-elastic">How We Handle Pull Requests at Elastic</a> provides a good overview. If someone approves your PR you can submit the code contribution to the Elastic Contributor Program, where you will share the link of the PR. After submitting we also encourage you to post about it on social media. This is a lot of work and your efforts deserve to be appreciated.
We hope that this blog post has helped you to start your journey for contributing code to the community. If you have any questions about how to contribute, please feel free to reach out to us at <a href="mailto:contributors@elastic.co">contributors@elastic.co</a>.

elastic-contributor-program-banner.jpg

elastic-contributor-program-thumbnail.jpg

Elastic Contributor Program: How to contribute code

Knowledge sharing is an important part of the open source community, and written content is a great way to share your knowledge. Not sure what to write about or how to get started? We’ll share a few tips on writing about your Elastic experience.

At Elastic, we believe in the <a href="https://en.wikipedia.org/wiki/Democratization_of_knowledge">democratization of knowledge</a>. This is part of our open source roots. The open source model advocates that everyone should have access to code that represents knowledge — which entails research, experimentation, testing, and time. Code is important, but what really makes the difference is the knowledge behind the code, and thanks to open source, this knowledge becomes available for anyone to use, build on, and evolve.
There are tons of ways to share knowledge besides contributing with code, such as <a href="/blog/elastic-contributor-program-how-to-organize-an-elastic-meetup">organizing meetups</a>, <a href="/blog/elastic-contributor-program-tips-for-speaking-at-an-event">speaking at an event</a>, or creating content. We created the <a href="/community/contributor">Elastic Contributor Program</a> to encourage knowledge sharing in our community and to recognize and reward the hard work of our awesome contributors.
In this blog post, we’ll cover a few tips on how to get started sharing your experiences with the community in writing.
 <h2>Getting started</h2>First, let’s clarify what qualifies as written content for the Elastic Contributor Program. In order to receive points the written content must be at least 200 words (or roughly 10 lines) and must be centered on Elastic products or solutions. If you happen to speak more than one language, you can also translate <a href="/blog">elastic.co blog posts</a> for the chance to earn additional points in the Contributor Program! Be sure to check out the <a href="/community/contributor/rules">Elastic Contributor Program rules page</a> for the full rules.
The good news is that the rules are pretty open ended — there’s no limit to what you can create! But you might ask yourself: Why should I spend my time writing? One reason is that written content is a great way to showcase your work and build your career. It’s not uncommon for developers in the community to struggle to get acknowledgement because, ultimately, there’s no easy way to verify their work and experience. Sharing your work by putting your experiences into writing is an effective way to demonstrate your abilities while also helping other developers learn from you.
 <h2>Finding a topic to write about</h2>So you’ve decided to take the leap and write something — but where do you begin? You might think that the first step in writing something is to get creative. But instead of focusing on creativity, try focusing on your personal experiences. Carefully observe what you’re building in your work every day. Take a closer look at the small things you create, change, and improve to get something done. You’ll probably find lots of interesting things to talk about.
Writing based on personal experience is powerful because it allows us to share practical experience, which everybody loves. For example, a blog post that talks about controlling memory usage for aggregations in Elasticsearch is good — but a post that discusses which knobs you had to switch to achieve faster aggregation results is way better.
As you start to think about putting your experiences down in writing, consider telling your story in one of the following ways:
<ul>
	<li>Journey: A journey is one of the most popular story types. Your journey captures the decisions, struggles, and consequences that you went through in order to accomplish something. To tell an effective story, you’ll want to explain the trajectory you took to get to your desired outcome — for example, maybe you had a project where you migrated from single indices to data streams to handle time series data more efficiently using hot, warm, and cold data nodes. Be sure to explain the desired outcome before getting into the details of the journey so your readers can understand the steps you took. Your readers might be trying to accomplish the same thing and they’ll want to know if your journey is applicable to them.</li>
</ul><ul>
	<li>Use case: A use case story is a variation of a journey, but is more structured and usually has four main sections: context, problem, solution, and results. Use case stories are good for sharing the history of a project, and they tend to be more successful when they focus on a specific industry. For instance, two companies adopting Elastic APM will end up with the same benefits, but if they’re in different industries their individual use cases will be unique. Capturing this uniqueness is key for telling a use case story.</li>
</ul><ul>
	<li>Lessons learned: This type of content focuses on the things that you’ve learned while working with a specific technology. It’s impossible for a technology to foresee all possible scenarios where it will be used, so if you’ve discovered something new during your work with the technology then this is a great opportunity to write something up. It’s common to use a cause and effect framework for this type of story. The effect is what readers are looking to understand. For example, do you know how Elasticsearch may behave when used with the new garbage collector from the JDK 12? What are the pros and cons? If this piqued your interest, then it may pique someone else’s, too.</li>
</ul> <h2>Turning ideas into action</h2>So far we’ve covered how to come up with ideas for what to write about. But how do you actually start the writing process?
First, before you even get your first word down, remember: writing isn’t about producing something that’s perfect. Instead, focus on creating something that will be useful to your reader. In order to do that, it’s important to understand your target audience. Properly understanding your audience will help a lot in managing your expectations about how much effort and time to put in your work — which hopefully will lead to less frustration.
For example, if you’re planning to write about a lesson learned, then you need to evaluate whether the subject you’re writing about is a well-known concept. If it is, then your content doesn’t need to provide a detailed overview before getting into the guts of the story. If you’re writing a blog targeting Java developers, you don’t need to explain what the JVM is.
Next you’ll want to think about the best format for your content. Although there are many types of writing out there, it might be easiest to think in terms of two main types: longer-form, formal articles and more casual pieces like blog posts. For more casual writing, such as a post on your personal blog, it’s best to keep it short and high-level and focus on a specific topic, like this one that shows <a href="/blog/how-to-run-elastic-cloud-on-kubernetes-from-azure-kubernetes-service">how to run Elastic Cloud on Kubernetes from Azure</a>. Formal articles are usually longer, provide deeper context, and may explore different facets of a topic or multiple topics, like this one about <a href="/blog/benchmarking-and-sizing-your-elasticsearch-cluster-for-logs-and-metrics">benchmarking and sizing Elasticsearch clusters for logs and metrics</a>.
If you’re writing about a journey, then you might want to write a longer piece, because you’ll need to provide a good amount of details before jumping into any conclusions. The tone for longer pieces tends to be more educational and scholarly. Use cases and lessons learned can be written in a more informal, blog post style, as they tend to be short and sweet and use a tone that is more laid back and sometimes even witty.
Your unique communication style also plays a key role in your writing. We all have different communication styles and ways of expressing our thoughts. This is a great thing — in fact, it’s part of <a href="/about/our-source-code">Elastic's Source Code</a>. So whatever your communication style, please embrace it! The unique way you create emphasis, how you break down concepts into bite-sized chunks, and even your sense of humor is what makes good content. If you’d like to refer to guidelines for how we write at Elastic, feel free to check out our <a href="https://brand.elastic.co/302f66895/p/072ccc-naming-guide">naming guidelines</a> and our <a href="https://brand.elastic.co/302f66895/p/194a3b-writing-style-guide">writing style guide page</a>.
Finally, make sure to proofread your writing before you publish. This means making sure that the grammar is impeccable and your thoughts are clear. Try reading your writing several times and revisiting problematic areas. If possible, ask a friend to provide feedback as well. Be open to feedback, especially feedback on areas that might be unclear.
We hope that this blog post has helped you to start your journey in contributing written content to the community. If you have any questions about how to contribute, please feel free to reach out to us at <a href="mailto:contributors@elastic.co">contributors@elastic.co</a>.

Articles by Ricardo Ferreira

No more searching for a needle in a haystack: A world where Elastic & StackState team up

Elastic Contributor Program: How to contribute code

Elastic Contributor Program: Tips for creating written content

Products & Solutions

Company

Resources

Solutions

Elastic (ELK) Stack

Register Today

Featured topics

News

Articles by Ricardo Ferreira

No more searching for a needle in a haystack: A world where Elastic & StackState team up

Elastic Contributor Program: How to contribute code

Elastic Contributor Program: Tips for creating written content