Sign up for a live Kubernetes or DevSecOps demo

Click here

Resource Center

Browse our library of ebooks, solutions briefs, research reports, case studies, webinars and more.

All resources

18 of 39 results

Blog

Serverless Computing for Dummies: AWS vs. Azure vs. GCP

Blog

Multi-Cloud Security Myths

Insight

Microsoft Azure 101

Blog

The Cloud SIEM market is validated by Microsoft, Google, and AWS

Blog

Clearing the Air: What Is Cloud Native?

Blog

Where to Find IIS Log Files

Blog

The Key Message from KubeCon NA 2018: Prometheus is King

Blog

Exploring Nordcloud’s Promise to Deliver 100 Percent Alert-Based Security Operations to Customers

Blog

How to Use the New Sumo Logic Terraform Provider for Hosted Collectors

Over the years, automation has become a key component in the management of the entire software release lifecycle. Automation helps teams get code from development into the hands of users faster and more reliably. While this principle is critical to your source code and continuous integration and delivery processes, it is equally essential to the underlying infrastructure you depend on. As automation has increased, a new principle for managing infrastructure has emerged to prevent environment drift and ensure your infrastructure is consistently and reliably provisioned. What Is Infrastructure as Code? Infrastructure-as-code (IaC) is a principle where infrastructure is defined using a declarative model and version controlled right along with your source code. The desired infrastructure is declared in a higher level descriptive language. Every aspect of your infrastructure, including servers, networks, firewalls and load balancers can be declared using this model. The infrastructure gets provisioned from the defined model automatically with no manual intervention required. This provisioning happens with a tool that interacts with APIs to spin up your infrastructure as needed. IaC ensures that your infrastructure can be created and updated reliably, safely and consistently anytime you need. It can be challenging to implement or practice IaC without the proper tools because it requires a lot of scripting, which can also be very time consuming. Luckily, there are a few out there that currently exist to help DevOps teams practice IaC, including one well-known and widely-used tool, Terraform. Why Terraform? Terraform is an open source tool developed by HashiCorp to address the needs of IaC. Terraform can be used to create, manage and update infrastructure resources. You can use Terraform to manage physical machines, virtual machines (VMs) load balancers, firewalls and many other resources. It provides ways to represent almost any type of infrastructure. In Terraform, you use a “provider” to define these resources. A provider understands the various APIs and contracts required to create, manage and update the various resources. Providers are created by IaaS offerings such as Amazon Web Services (AWS), Google Cloud Platform (GCP) and Microsoft Azure or OpenStack or SaaS offerings like Terraform Enterprise and CloudFlare. The provider defines a declarative model to create the various infrastructure resources it offers. Introducing the Sumo Logic Terraform Provider That’s why today we’re happy to announce that we have now released a Terraform Provider for Sumo Logic, and just in time for HashiConf ‘18 this week in San Francisco. This provider helps you treat your Sumo Logic Hosted Collectors and Sources as code, ensuring consistency across your cloud infrastructure monitoring for AWS, GCP, Azure, and other cloud environments supported by Terraform. Using our Terraform provider along with the existing provider you use to manage your cloud infrastructure, you can easily set up Sumo Logic to monitor those resources and link that set up directly to the provisioning of your infrastructure. For example, if you are using the AWS provider to create your Elastic Load Balancer (ELB) and an S3 bucket to capture those logs, you can also define a Sumo Logic Hosted with an ELB source that brings those logs from the S3 bucket straight into the Sumo Logic platform. This configuration is declared in code and version controlled to give a consistent and reliable set up to create and monitor your infrastructure. Let’s walk through an example of how you can use the Terraform provider. In this example, we will use the Sumo Logic Terraform provider to create a Hosted Collector with an HTTP Source. I will be demonstrating this example using my Mac. Step-by-Step Instructions The first thing we need to do is install Terraform. I will be installing Terraform using Homebrew, a package manager for Mac OSX. Once Terraform is installed, we need to download the Sumo Logic Terraform Provider from the GitHub release page. In this case, I will be downloading the binary for Mac OSX. We then need to copy it to the Terraform plugins directory. Next we need to initialize Terraform to ensure it is ready to go by running ‘terraform init.’ With the provider in place and Terraform initialized, we can now define a configuration file for our Hosted Collector and HTTP Source. The following Terraform configuration will create a Hosted Collector with an HTTP source. provider “sumologic” { access_id = “sumo-logic-access-id” access_key = “sum-logic-access-key” environment = “us2” } resource “sumologic_collector” “example_collector” { name = “Hosted Collector” category = “my/source/category” } resource “sumologic_http_source” “example_http_source” { name = “HTTP Source” category = “my/source/category” collector_id = “${sumologic_collector.example_collector.id}” } Let’s break down the above file. The provider section defines the required properties for the Sumo Logic provider. You need to create an Access ID and Access Key which will be the credentials for the Sumo Logic API. The environment should be set based on where your Sumo Logic account is located, in this case it is US2. There are then two resource sections, where we define the Hosted Collector and the HTTP Source. An HTTP source requires the ID of the collector you wish to assign it to. In the HTTP source resource section you will see we reference the ID of the collector by using the hosted collector we created above. With the file in place and all inputs in, we can now spin up our collector. To have Terraform create this for us, we simply need to run terraform apply. Terraform will prompt us to ensure we want to do this action. After entering yes, you should see the following output indicating that our resources have been created. And now if we go to Sumo Logic and look at our Collector page, we see we have our Hosted Collector and HTTP source, just like we defined in our configuration file! Our Terraform provider allows you to configure your Hosted Collectors and Sources with all the same properties you would expect and you can see all the different options in our Documentation page. More To Come At Sumo Logic, we are developing many new APIs to give our users full control over the provisioning of all their Sumo Logic configurations. As these APIs continue to roll out, we will be updating our provider to expose these additional resources. This will allow users to manage all aspects of Sumo Logic, including Collection, User Management, and Content as code, as well as have the ability to automate every aspect of Sumo Logic. Additional Resources Download our 2018 State of Modern Apps and DevSecOps in the Cloud report for trending insights into how some of the world’s top cloud savvy companies like Twitter, Airbnb, Adobe, Salesforce, etc. build and manage their modern applications. Want to know how to how to integrate Sumo Logic’s monitoring platform into your Terraform-scripted cloud infrastructure for EC2 resources? Read the blog. Thinking about adopting modern microservices-based infrastructure? Check out part one and part two of our blog series on how to manage Kubernetes/Docker with Sumo Logic.

Blog

How to Monitor Azure Services with Sumo Logic

Brief

The State of Modern Applications & DevSecOps in the Cloud - 2018

Blog

Sumo Logic's Third Annual State of Modern Apps and DevSecOps in the Cloud Report is Here!

Brief

The State of Modern Applications in the Cloud Report - 2017

Blog

11 New Google Cloud Platform (GCP) Apps for Continued Multi-Cloud Support

Blog

Sumo Logic For Support and Customer Success Teams

*Authored by Kevin Keech, Director of Support at Sumo Logic, and Graham Watts, Senior Solutions Engineer at Sumo Logic Many Sumo Logic customers ask, “How can I use Sumo Logic for support and customer success teams?” If you need a better customer experience to stay ahead of the competition, Sumo Logic can help. In this post, I will describe why and how support and customer success teams use Sumo Logic, and summarize the key features to use in support and customer success use cases. Why Use Sumo Logic For Support and Customer Success Teams? Improved Customer Experience Catch deviations and performance degradation before your customers report it Using dashboards and scheduled alerts, your CS and Support teams can be notified of any service impacting issues and can then reach out and provide solutions before your customers may ever know they have a problem This helps your customers avoid experiencing any frustrations with your service, which in the past may have led them to look into competitive offerings Improve your Net Promoter Score (NPS) and Service Level Agreements (SLAs) Alert team members to reach out to a frustrated customer before they go to a competitors website or log out Efficiency and Cost Savings – Process More Tickets, Faster Sumo Logic customers report an increase in the number of support tickets each team member can handle by 2-3x or more Direct access to your data eliminates the need for your Support team to request access and wait for engineering resources to grant access This leads to a higher level of customer satisfaction, and allows you to reallocate engineering time to innovate and enhance your product offerings Your support reps can perform real-time analysis of issues as they are occurring, locate the root of a problem, and get your customers solutions quicker Customers report that using LogReduce cuts troubleshooting time down from hours/days to minutes As your teams and products grow, team members can process more tickets instead of needing to hire more staff Security Eliminate the need to directly log into servers to look at logs – you can Live Tail your logs right in Sumo Logic or via a CLI Use Role Based Access Control to allow teams to view only the data they need How to Use Sumo Logic For Support and Customer Success Teams Key features that enable your Support Team, Customer Success Team, or another technical team while troubleshooting are: Search Templates See here for a video tutorial of Search Templates Form based search experience – no need for employees to learn a query language Users type in human-friendly, easy to remember values like “Company Name” and Sumo will look up and inject complex IDs, like “Customer ID” or some other UUID, into the query, shown to the right: LogReduce Reduce 10s or 100s of thousands of log messages into a few patterns with the click of a button This reduces the time it takes to identify the root cause of an issue from hours or days to minutes In the below example, a bad certificate and related tracebacks are exposed with LogReduce Dashboards Dashboard filters – Auto-populating dashboard filters for easy troubleshooting TimeCompare – Is now ‘normal’ compared to historical trends? The example below shows production errors or exceptions today, overlaid with the last 7 days of production errors or exceptions:

Blog

Comparing Kubernetes Services on AWS vs. Azure vs. GCP

Blog

Log Analysis on the Microsoft Cloud

The Microsoft Cloud, also known as Microsoft Azure, is a comprehensive collection of cloud services available for developers and IT professionals to deploy and manage applications in data centers around the globe. Managing applications and resources can be challenging, especially when the ecosystem involves many different types of resources, and perhaps multiple instances of each. Being able to view logs from those resources and perform log analysis is critical to effective management of your environment hosted in the Microsoft Cloud. In this article, we’re going to investigate what logging services are available within the Microsoft Cloud environment, and then what tools are available to assist you in analyzing those logs. What Types of Logs are Available? The Microsoft Cloud Infrastructure supports different logs depending on the types of resources you are deploying. Let’s look at the logs that are gathered within the ecosystem and then investigate each in more depth. Activity Logs Diagnostic Logs Application logs are also gathered within the Microsoft Cloud. However, these are limited to compute resources and are dependent on the technology used within the resource, and application and services which are deployed with that technology. Activity Logs All resources report their activity within the Microsoft Cloud ecosystem in the form of Activity Logs. These logs are generated as a result of some different categories of events. Administrative – Creation, deletion and updating of the resource. Alerts – Conditions which may be cause for concern, such as elevated processing or memory usage. Autoscaling – When the number of resources is adjusted due to autoscale settings. Service Health – Related to the health of the environment in which the resource is hosted. These logs contain information related to events occurring external to the resource. Diagnostic Logs Complementary to the activity logs are the diagnostic logs. Diagnostic logs provide a detailed view into the operations of the resource itself. Some examples of actions which would be included in these logs are: Accessing a secret vault for a key Security group rule invocation Diagnostic logs are invaluable in troubleshooting problems within the resource and gaining additional insight into the interactions with external resources from within the resource being monitored. This information is also valuable in determining the overall function and performance of the resource. Providing this data to an analysis tool can offer important insights which we’ll discuss more in the next section. Moving Beyond a Single Resource Log viewing tools and included complex search filters are available from within the Microsoft Cloud console. However, these are only useful if you are interested in learning more about the current state of a specific instance. And while there are times when this level of log analysis is valuable and appropriate, sometimes it can’t accomplish the task. If you find yourself managing a vast ecosystem consisting of multiple applications and supporting resources, you will need something more powerful. Log data from the Microsoft Cloud is available for access through a Command Line Interface (CLI), REST API and PowerShell Cmdlet. The real power in the logs lies in being able to analyze them to determine trends, identify anomalies and automate monitoring so that engineers can focus on developing additional functionality, improving performance and increasing efficiencies. There are some companies which have developed tools for aggregating and analyzing logs from the Microsoft Cloud, including Sumo Logic. You can learn more about the value which Sumo Logic can provide from your log data by visiting their Microsoft Azure Management page. I’d like to touch on some of the benefits here in conclusion. Centralized aggregation of all your log data, both from the Microsoft Cloud and from other environments, makes it easier to gain a holistic view of your resources. In addition to making this easier for employees to find the information they need quickly, it also enhances your ability to ensure adherence to best practices and maintain compliance with industry and regulatory standards. Use of the Sumo Logic platform also allows you to leverage their tested and proven algorithms for anomaly detection, and allows you to segregate your data by source, user-driven events, and many other categories to gain better insight into which customers are using your services, and how they are using them.

Blog

4 Reasons Why I Chose Azure: A Developer's Perspective

Before Azure and AWS, Microsoft development teams would need a server on their local network that would manage change control and commits. Once a week, a chosen developer would compile and deploy the application to a production server. Now developers have the option of creating cloud applications in Visual Studio and connecting their projects directly to an Azure cloud server. For a Windows developer, Azure was the choice I made to develop my own software projects and manage them in the cloud due to the easy integration between my development desktop and Azure cloud instances. Azure has similar services as other cloud providers, but it has some advantages for Microsoft developers that need to deploy applications for the enterprise. The biggest advantage for an enterprise is that it reduces the amount of on-site resources needed to support a developer team. For instance, the typical Microsoft-based enterprise has a team of developers, a staging server, a development server, QA resources, Jira, and some kind of ticketing system (just to name a few). With Azure, the team can set up these resources without the real estate or the hardware on-site. It also has integrated IaaS, so you can create a seamless bond between your internal network and the cloud infrastructure. In other words, your users will never know if they are working on a local server or running applications on Azure. The Dashboard For anyone who has managed Windows servers, the dashboard (Azure calls it your portal) is intuitive. The difficult part of starting an Azure account is understanding all of the options you see in the dashboard. For developers used to local environments where you need to provision multiple resources for one application, it's important to understand that everything you need to build an application is at your fingertips. You no longer need to go out and purchase different services such as SSL and database software and install it. You just click the service that you want and click "Create" in the Azure portal and Microsoft builds it into your service agreement. If you pay as you go, then you only pay for the resources that you use. You can build APIs, services, start virtual servers, and even host WordPress sites from your portal. In the image above, I've blacked out the names of my resources for security reasons, but you can see that I have a web application, an SSL certificate, two databases (one MySQL and one MSSQL), email services and a vault (for the SSL cert) in Azure. I have an individual plan and don't use many resources from their servers, so I pay about $100 a month for a small WordPress site. When I had two web applications running, I paid about $150 a month. Integration with Visual Studio The main reason I use Azure is for it's easy integration with my Visual Studio projects. For Windows projects, integration between Visual Studio and Azure is as simple as creating a web application and copying the connection information into your projects. Once you've created the connection in Visual Studio, you can use Azure for change control and promote code directly from your development computer. For a simple web application, Microsoft offers a web app and a web app with SQL. This should be self-explanatory. If you just want to build a web application and don't need a database, then you choose the first option. The second one will set up a web app and a SQL Server. You aren't limited to a Windows environment either. When you create a web app, Azure asks if you want to use Windows or Linux. When you create your application, it sits on a subdomain named <your_app_name>.azurewebsites.net. This will be important when you set up your TLD. This feature is the downside of using Azure over traditional hosting. When you set up your TLD, you set up a CNAME and configure a custom domain in your Azure settings. When search engines crawl your site, sometimes they index this subdomain instead of only the TLD. This makes it difficult to work with when you use applications such as WordPress. When you install WordPress, you install it on the subdomain, so WordPress has the subdomain in all of its settings. This causes errors when you promote the site to your TLD, and you must do a global database search and replace to remove the it from your settings. I found this was one con to using Azure for my websites. After you create the web app, you're shown basic information to get started should you just want to upload files to the new location using FTP. The "Get publish profile" provides you with a downloadable text file that you use to connect Visual Studio. You can also connect it directly to your own GitHub repository. As a matter of fact, Microsoft will generate pre-defined settings for several repositories. After you download one of these files, you import the settings directly into your profile and you're automatically connected. When I work in Visual Studio with an Azure connection, I check out files, edit them and check them back in as I code. It feels exactly like the old-school Team Foundation Server environment except I don't have to buy the expensive equipment and licenses to host an internal Microsoft Windows server. Easy VM Creation for Testing Third-Party Software Occasionally, I get a customer that has an application that they want me to test. It's usually in beta or it's their recent stable release but it's something that I wouldn't normally use on my machine. It's dangerous for me to install third-party software on my work machine. Should my customers' software crash my computer, I lose important data. Not only could I lose data, but I don't know what type of software I'm installing on my important developer machine connected to my home network. I don't want anything to have the ability to search my home network and storage. With an Azure VM, I not only keep the software off of my local machine, but it's shielded from my local network too. I could install a VM on my local desktop, but I like to keep this machine clean from anything other than what I need to develop and code. I use Azure VMs to install the software, and then I can destroy the VM when I'm done with it. What's great about Azure is that they have several pre-installed operating systems and frameworks to choose from. Here are just a few: Some other platforms not shown above but can be installed on an Azure VM: Citrix XenDesktop Kali Linux Cisco CSR SQL Server cluster Kiteworks Suse Linux Jira Magento WordPress When I'm working with client software, I use the default Windows Server installation, which is 2016. Microsoft adds the latest operating system to its list as they are released. It's an Azure advantage over working with traditional VPS service. With traditional service, you must ask the host to upgrade your operating system and change your service. With Azure, you spin up a new VM with any operating system you choose. I then use the VM to install the software, work with it until I'm finished a project, and then destroy the VM when I'm done. Because I only use the VM for a short time and don't connect it to any resource-intensive applications, it only costs me a few extra dollars a month. But I keep third-party apps "sandboxed" from my own network without using local resources. Working with WordPress on Azure Occasionally organizations have a separate WordPress site for content even with a team of Windows developers. It's easier for marketing to publish content with WordPress. Instead of using a separate shared host, Azure has the option to create an app with WordPress pre-installed. Most people think running WordPress on a Windows server is senseless, but you get some kind of security from standard hacks that look for .htaccess or Apache vulnerabilities, and you can keep your web services all in one place. It only costs a few dollars to host the WordPress site, but you pay for traffic that hits the service so it might be much more if you have a high-traffic blog. Azure has its Insights services as well, so you can monitor WordPress unlike traditional shared or VPS services where you need a third-party application. You also get monitoring and all the available infrastructure such as load balancing, SSL, and monitoring should you need it with the WordPress site. These aren't available with simple shared or VPS hosting. While running WordPress on Windows seems counterintuitive, running it in Azure is more beneficial for the enterprise that needs to keep detailed statistics on site usage and security from script kiddies that attack any public WordPress site with poor Linux management. Is Azure Better than AWS? Most people will tell you that AWS is a better choice, but I preferred Azure's portal. I found spinning up services was more intuitive, but what sold me was the integration into Visual Studio. If you're in an enterprise, the one advantage of Azure is that you can integrate Active Directory Services so that your network expands into Azure's cloud IaaS. This would be much better than building a separate portal that you must control with individual security settings. This eliminates the possibility of accidentally exposing data from incorrect security settings. If you decide to try Azure, they give you the first 30 days free. AWS gives you 12 months, so users have longer to figure out settings. I found Azure beneficial and kept paying for a low-traffic, low-resource account until I could figure out if I wanted to permanently use it. I've had an account for two years now and don't plan to ever switch.

Featured collections