Security updates have been issued by Debian (batik, cups, gitlab, ming, and xdg-utils), Fedora (dpdk, firefox, glibc, nodejs-deep-extend, strongswan, thunderbird, thunderbird-enigmail, wavpack, xdg-utils, and xen), Gentoo (ntp, rkhunter, and zsh), openSUSE (Chromium, GraphicsMagick, jasper, opencv, pdns, and wireshark), SUSE (jasper, java-1_7_1-ibm, krb5, libmodplug, and openstack-nova), and Ubuntu (thunderbird).
Security updates have been issued by Arch Linux (lib32-curl, lib32-libcurl-compat, lib32-libcurl-gnutls, libcurl-compat, and libcurl-gnutls), CentOS (firefox), Debian (imagemagick), Fedora (exiv2, LibRaw, and love), Gentoo (chromium), Mageia (kernel, librelp, and miniupnpc), openSUSE (curl, enigmail, ghostscript, libvorbis, lilypond, and thunderbird), Red Hat (Red Hat OpenStack Platform director), and Ubuntu (firefox).
Security updates have been issued by Arch Linux (curl and zathura-pdf-mupdf), Debian (libmad and vlc), openSUSE (enigmail), Red Hat (collectd, Red Hat OpenStack Platform director, and sensu), and SUSE (firefox, ghostscript, and mysql).
Security updates have been issued by Debian (drupal7, graphicsmagick, libdatetime-timezone-perl, thunderbird, and tzdata), Fedora (gd, libtiff, mozjs52, and nmap), Gentoo (thunderbird), Red Hat (openstack-tripleo-common, openstack-tripleo-heat-templates and sensu), SUSE (kernel, libvirt, and memcached), and Ubuntu (icu, librelp, openssl, and thunderbird).
Security updates have been issued by Arch Linux (mbedtls), CentOS (gcab and java-1.7.0-openjdk), Debian (drupal7, lucene-solr, wavpack, and xmltooling), Fedora (dnsmasq, gcab, gimp, golang, knot-resolver, ldns, libsamplerate, mingw-OpenEXR, mingw-poppler, python-crypto, qt5-qtwebengine, sblim-sfcb, systemd, unbound, and wavpack), Mageia (ioquake3, TiMidity++, tomcat, tomcat-native, and wireshark), openSUSE (systemd and zziplib), Red Hat (erlang and openstack-nova and python-novaclient), and SUSE (kernel).
Security updates have been issued by Arch Linux (dnsmasq, libmupdf, mupdf, mupdf-gl, mupdf-tools, and zathura-pdf-mupdf), CentOS (kernel), Debian (smarty3, thunderbird, and unbound), Fedora (bind, bind-dyndb-ldap, coreutils, curl, dnsmasq, dnsperf, gcab, java-1.8.0-openjdk, libxml2, mongodb, poco, rubygem-rack-protection, transmission, unbound, and wireshark), Red Hat (collectd, erlang, and openstack-nova), SUSE (bind), and Ubuntu (clamav and webkit2gtk).
Post Syndicated from Blogs on Grafana Labs Blog original https://grafana.com/blog/2018/01/05/timeshiftgrafanabuzz-1w-issue-28/
Happy new year! Grafana Labs is getting back in the swing of things after taking some time off to celebrate 2017, and spending time with family and friends. We’re diligently working on the new Grafana v5.0 release (planning v5.0 beta release by end of January), which includes a ton of new features, a new layout engine, and a polished UI. We’d love to hear your feedback!
Latest Stable Release
Grafana 4.6.3 is now available. Latest bugfixes include:
- Gzip: Fixes bug Gravatar images when gzip was enabled #5952
- Alert list: Now shows alert state changes even after adding manual annotations on dashboard #99513
- Alerting: Fixes bug where rules evaluated as firing when all conditions was false and using OR operator. #93183
- Cloudwatch: CloudWatch no longer display metrics’ default alias #101514, thx @mtanda
From the Blogosphere
Why Observability Matters – Now and in the Future: Our own Carl Bergquist teamed up with Neil Gehani, Director of Product at Weaveworks to discuss best practices on how to get started with monitoring your application and infrastructure. This video focuses on modern containerized applications instrumented to use Prometheus to generate metrics and Grafana to visualize them.
How to Install and Secure Grafana on Ubuntu 16.04: In this tutorial, you’ll learn how to install and secure Grafana with a SSL certificate and a Nginx reverse proxy, then you’ll modify Grafana’s default settings for even tighter security.
Monitoring Informix with Grafana: Ben walks us through how to use Grafana to visualize data from IBM Informix and offers a practical demonstration using Docker containers. He also talks about his philosophy of sharing dashboards across teams, important metrics to collect, and how he would like to improve his monitoring stack.
Monitor your hosts with Glances + InfluxDB + Grafana: Glances is a cross-platform system monitoring tool written in Python. This article takes you step by step through the pieces of the stack, installation, confirguration and provides a sample dashboard to get you up and running.
GrafanaCon Tickets are Going Fast!
Lock in your seat for GrafanaCon EU while there are still tickets avaialable! Join us March 1-2, 2018 in Amsterdam for 2 days of talks centered around Grafana and the surrounding monitoring ecosystem including Graphite, Prometheus, InfluxData, Elasticsearch, Kubernetes, and more.
We have some exciting talks lined up from Google, CERN, Bloomberg, eBay, Red Hat, Tinder, Fastly, Automattic, Prometheus, InfluxData, Percona and more! You can see the full list of speakers below, but be sure to get your ticket now.
GrafanaCon EU will feature talks from:
In between code pushes we like to speak at, sponsor and attend all kinds of conferences and meetups. We also like to make sure we mention other Grafana-related events happening all over the world. If you’re putting on just such an event, let us know and we’ll list it here.
Carl Bergquist – Quickie: Monitoring? Not OPS Problem
Why should we monitor our system? Why can’t we just rely on the operations team anymore? They use to be able to do that. What’s currently changing? Presentation content: – Why do we monitor our system – How did it use to work? – Whats changing – Why do we need to shift focus – Everyone should be on call. – Resilience is the goal (Best way of having someone care about quality is to make them responsible).
Leonard Gram – Presentation: DevOps Deconstructed
What’s a Site Reliability Engineer and how’s that role different from the DevOps engineer my boss wants to hire? I really don’t want to be on call, should I? Is Docker the right place for my code or am I better of just going straight to Serverless? And why should I care about any of it? I’ll try to answer some of these questions while looking at what DevOps really is about and how commodisation of servers through “the cloud” ties into it all. This session will be an opinionated piece from a developer who’s been on-call for the past 6 years and would like to convince you to do the same, at least once.
Tweet of the Week
We scour Twitter each week to find an interesting/beautiful dashboard and show it off! #monitoringLove
— James L. (@Thaolia) December 23, 2017
Awesome! Let us know if you have any questions – we’re happy to help out. We also have a bunch of screencasts to help you get going.
How are we doing?
That’s a wrap! Let us know what you think about timeShift. Submit a comment on this article below, or post something at our community forum. See you next year!
Security updates have been issued by Arch Linux (firefox, flashplugin, lib32-flashplugin, and mediawiki), CentOS (kernel and php), Debian (firefox-esr, jackson-databind, and mediawiki), Fedora (apr, apr-util, chromium, compat-openssl10, firefox, ghostscript, hostapd, icu, ImageMagick, jackson-databind, krb5, lame, liblouis, nagios, nodejs, perl-Catalyst-Plugin-Static-Simple, php, php-PHPMailer, poppler, poppler-data, rubygem-ox, systemd, webkitgtk4, wget, wordpress, and xen), Mageia (flash-player-plugin, icu, jackson-databind, php, and roundcubemail), Oracle (kernel and php), Red Hat (openstack-aodh), SUSE (wget and xen), and Ubuntu (apport and webkit2gtk).
Post Syndicated from Blogs on Grafana Labs Blog original https://grafana.com/blog/2017/08/25/timeshiftgrafanabuzz-1w-issue-10/
This week, in addition to the articles we collected from around the web and a number of new Plugins and updates, we have a special announcement. GrafanaCon EU has been announced! Join us in Amsterdam March 1-2, 2018. The call for papers is officially open! We’ll keep you up to date as we fill in the details.
Grafana <3 Prometheus
Last week we mentioned that our colleague Carl Bergquist spoke at PromCon 2017 in Munich. His presentation is now available online. We will post the video once it’s available.
From the Blogosphere
Grafana-based GUI for mgstat, a system monitoring tool for InterSystems Caché, Ensemble or HealthShare: This is the second article in a series about Making Prometheus Monitoring for InterSystems Caché. Mikhail goes into great detail about setting this up on Docker, configuring the first dashboard, and adding templating.
Installation and Integration of Grafana in Zabbix 3.x: Daniel put together an installation guide to get Grafana to display metrics from Zabbix, which utilizes the Zabbix Plugin developed by Grafana Labs Developer Alex Zobnin.
Visualize with RRDtool x Grafana: Atfujiwara wanted to update his MRTG graphs from RRDtool. This post talks about the components needed and how he connected RRDtool to Grafana.
Huawei OceanStor metrics in Grafana: Dennis is using Grafana to display metrics for his storage devices. In this post he walks you through the setup and provides a comprehensive dashboard for all the metrics.
Grafana on a Raspberry Pi2: Pete discusses how he uses Grafana with his garden sensors, and walks you through how to get it up and running on a Pi2.
This week was pretty active on the plugin front. Today we’re announcing two brand new plugins and updates to three others. Installing plugins in Grafana is easy – if you have Hosted Grafana, simply use the one-click install, if you’re using an on-prem instance you can use the Grafana-cli.
IBM APM Data Source – This plugin collects metrics from the IBM APM (Application Performance Management) products and allows you to visualize it on Grafana dashboards. The plugin supports:
- IBM Tivoli Monitoring 6.x
- IBM SmartCloud Application Performance Management 7.x
- IBM Performance Management 8.x (only on-premises version)
Datatable Panel – Lots of changes in the latest update to the Datatable Panel Here are some highlights from the changelog:
- NEW: Export options for Clipboard/CSV/PDF/Excel/Print
- NEW: Column Aliasing – modify the name of a column as sent by the datasource
- NEW: Added option for a cell or row to link to another page
- NEW: Supports Clickable links inside table
- BUGFIX: CSS files now load when Grafana has a subpath
- NEW: Added multi-column sorting – sort by any number of columns ascending/descending
- NEW: Column width hints – suggest a width for a named column
- BUGFIX: Columns from datasources other than JSON can now be aliased
This week’s MVC (Most Valuable Contributor)
Each week we highlight a contributor to Grafana or the surrounding ecosystem as a thank you for their participation in making open source software great.
Brian is the maintainer of two Grafana Plugins and this week he submitted substantial updates to both of them (Datatable and D3 Gauge panel plugins); and he says there’s more to come! Thanks for all your hard work, Brian.
Tweet of the Week
We scour Twitter each week to find an interesting/beautiful dashboard and show it off! #monitoringLove
The Dark Knight popping up in graphs seems to be a recurring theme!
This is the graph Jakub deserves, but not the one he needs right now.
— Jakub Libosvar (@cubeeek) August 22, 2017
What do you think?
That’s it for the 10th issue of timeShift. Let us know how we’re doing! Submit a comment on this article below, or post something at our community forum. Help us make this better!
Security updates have been issued by Mageia (atril, mpg123, perl-SOAP-Lite, and virtualbox), openSUSE (kernel and libzypp, zypper), Oracle (authconfig, bash, curl, gdm and gnome-session, ghostscript, git, glibc, gnutls, gtk-vnc, kernel, libreoffice, libtasn1, mariadb, openldap, openssh, pidgin, postgresql, python, qemu-kvm, samba, tcpdump, tigervnc and fltk, and tomcat), Red Hat (kernel, kernel-rt, openstack-neutron, and qemu-kvm), and SUSE (puppet and tcmu-runner).
Security updates have been issued by Arch Linux (postgresql, postgresql-libs, samba, and sudo), Debian (gajim, libpodofo, openldap, pngquant, qemu-kvm, sudo, and tiff), Fedora (lxterminal, menu-cache, and pcmanfm), Gentoo (sudo), openSUSE (libraw, miniupnpc, and sudo), Oracle (kernel, nss, and sudo), Red Hat (kernel and sudo), Scientific Linux (kernel and sudo), Slackware (sudo), SUSE (java-1_6_0-ibm, java-1_8_0-openjdk, openstack-components, and sudo), and Ubuntu (sudo).
Security updates have been issued by Debian (shadow), Fedora (rpcbind), Gentoo (gst-plugins-bad and tomcat), Red Hat (ansible and openshift-ansible, openstack-heat, and Red Hat OpenStack Platform director), and Ubuntu (bash, FreeType, linux-aws, linux-gke, linux-raspi2, linux-snapdragon, and linux-lts-xenial).
It seems that system administrators will never shake the need for backups,
even when they shove everything into the cloud. At the OpenStack Summit
in Boston last week, a session
by Ghanshyam Mann and Abhinav Agrawal of NEC laid out the requirements for
data and metadata in OpenStack—with principles that apply to any
virtualization or cloud deployment.
Over at Opensource.com, Rich Bowen looks at some of the new features in OpenStack Ocata, which was released back in February.
“First, it’s important to remember that the Ocata cycle was very short. We usually do a release every six months, but with the rescheduling of the OpenStack Summit and OpenStack PTG (Project Team Gathering) events, Ocata was squeezed into 4 months to realign the releases with these events. So, while some projects squeezed a surprising amount of work into that time, most projects spent the time on smaller features and finishing up tasks leftover from the previous release.
At a high level, the Ocata release was all about upgrades and containers, themes that I heard from almost every team I interviewed. Developers spoke of how we can make upgrades smoother, and how we can deploy bits of the infrastructure in containers. These two things are closely related, and there seems to be more cross-project collaboration this time around than I’ve noticed in the past.”
By James Penick, Cloud Architect & Gurpreet Kaur, Product Manager
A version of this byline was originally written for and appears in CIO Review.
A successful private cloud presents a consistent and reliable facade over the complexities of hyperscale infrastructure. It must simultaneously handle constant organic traffic growth, unanticipated spikes, a multitude of hardware vendors, and discordant customer demands. The depth of this complexity only increases with the age of the business, leaving a private cloud operator saddled with legacy hardware, old network infrastructure, customers dependent on legacy operating systems, and the list goes on. These are the foundations of the horror stories told by grizzled operators around the campfire.
Providing a plethora of services globally for over a billion active users requires a hyperscale infrastructure. Yahoo’s on-premises infrastructure is comprised of datacenters housing hundreds of thousands of physical and virtual compute resources globally, connected via a multi-terabit network backbone. As one of the very first hyperscale internet companies in the world, Yahoo’s infrastructure had grown organically – things were built, and rebuilt, as the company learned and grew. The resulting web of modern and legacy infrastructure became progressively more difficult to manage. Initial attempts to manage this via IaaS (Infrastructure-as-a-Service) taught some hard lessons. However, those lessons served us well when OpenStack was selected to manage Yahoo’s datacenters, some of which are shared below.
Centralized team offering Infrastructure-as-a-Service
Chief amongst the lessons learned prior to OpenStack was that IaaS must be presented as a core service to the whole organization by a dedicated team. An a-la-carte-IaaS, where each user is expected to manage their own control plane and inventory, just isn’t sustainable at scale. Multiple teams tackling the same challenges involved in the curation of software, deployment, upkeep, and security within an organization is not just a duplication of effort; it removes the opportunity for improved synergy with all levels of the business. The first OpenStack cluster, with a centralized dedicated developer and service engineering team, went live in June 2012. This model has served us well and has been a crucial piece of making OpenStack succeed at Yahoo. One of the biggest advantages to a centralized, core team is the ability to collaborate with the foundational teams upon which any business is built: Supply chain, Datacenter Site-Operations, Finance, and finally our customers, the engineering teams. Building a close relationship with these vital parts of the business provides the ability to streamline the process of scaling inventory and presenting on-demand infrastructure to the company.
Developers love instant access to compute resources
Our developer productivity clusters, named “OpenHouse,” were a huge hit. Ideation and experimentation are core to developers’ DNA at Yahoo. It empowers our engineers to innovate, prototype, develop, and quickly iterate on ideas. No longer is a developer reliant on a static and costly development machine under their desk. OpenHouse enables developer agility and cost savings by obviating the desktop.
Dynamic infrastructure empowers agile products
From a humble beginning of a single, small OpenStack cluster, Yahoo’s OpenStack footprint is growing beyond 100,000 VM instances globally, with our single largest virtual machine cluster running over a thousand compute nodes, without using Nova Cells.
Until this point, Yahoo’s production footprint was nearly 100% focused on baremetal – a part of the business that one cannot simply ignore. In 2013, Yahoo OpenStack Baremetal began to manage all new compute deployments. Interestingly, after moving to a common API to provision baremetal and virtual machines, there was a marked increase in demand for virtual machines.
Developers across all major business units ranging from Yahoo Mail, Video, News, Finance, Sports and many more, were thrilled with getting instant access to compute resources to hit the ground running on their projects. Today, the OpenStack team is continuing to fully migrate the business to OpenStack-managed. Our baremetal footprint is well beyond that of our VMs, with over 100,000 baremetal instances provisioned by OpenStack Nova via Ironic.
How did Yahoo hit this scale?
Scaling OpenStack begins with understanding how its various components work and how they communicate with one another. This topic can be very deep and for the sake of brevity, we’ll hit the high points.
1. Start at the bottom and think about the underlying hardware
Do not overlook the unique resource constraints for the services which power your cloud, nor the fashion in which those services are to be used. Leverage that understanding to drive hardware selection. For example, when one examines the role of the database server in an OpenStack cluster, and considers the multitudinous calls to the database: compute node heartbeats, instance state changes, normal user operations, and so on; they would conclude this core component is extremely busy in even a modest-sized Nova cluster, and in need of adequate computational resources to perform. Yet many deployers skimp on the hardware. The performance of the whole cluster is bottlenecked by the DB I/O. By thinking ahead you can save yourself a lot of heartburn later on.
2. Think about how things communicate
Our cluster databases are configured to be multi-master single-writer with automated failover. Control plane services have been modified to split DB reads directly to the read slaves and only write to the write-master. This distributes load across the database servers.
3. Scale wide
OpenStack has many small horizontally-scalable components which can peacefully cohabitate on the same machines: the Nova, Keystone, and Glance APIs, for example. Stripe these across several small or modest hardware. Some services, such as the Nova scheduler, run the risk of race conditions when running multi-active. If the risk of race conditions is unacceptable, use ZooKeeper to manage leader election.
4. Remove dependencies
In a Yahoo datacenter, DHCP is only used to provision baremetal servers. By statically declaring IPs in our instances via cloud-init, our infrastructure is less prone to outage from a failure in the DHCP infrastructure.
5. Don’t be afraid to replace things
Neutron used Dnsmasq to provide DHCP services, however it was not designed to address the complexity or scale of a dynamic environment. For example, Dnsmasq must be restarted for any config change, such as when a new host is being provisioned. In the Yahoo OpenStack clusters this has been replaced by ISC-DHCPD, which scales far better than Dnsmasq and allows dynamic configuration updates via an API.
6. Or split them apart
Some of the core imaging services provided by Ironic, such as DHCP, TFTP, and HTTPS communicate with a host during the provisioning process. These services are normally part of the Ironic Conductor (IC) service. In our environment we split these services into a new and physically-distinct service called the Ironic Transport Service (ITS). This brings value by:
- Adding security: Splitting the ITS from the IC allows us to block all network traffic from production compute nodes to the IC, and other parts of our control plane. If a malicious entity attacks a node serving production traffic, they cannot escalate from it to our control plane.
- Scale: The ITS hosts allow us to horizontally scale the core provisioning services with which nodes communicate.
- Flexibility: ITS allows Yahoo to manage remote sites, such as peering points, without building a new cluster in that site. Resources in those sites can now be managed by the nearest Yahoo owned & operated (O&O) datacenter, without needing to build a whole cluster in each site.
Be prepared for faulty hardware!
Running IaaS reliably at hyperscale is more than just scaling the control plane. One must take a holistic look at the system and consider everything. In fact, when examining provisioning failures, our engineers determined the majority root cause was faulty hardware. For example, there are a number of machines from varying vendors whose IPMI firmware fails from time to time, leaving the host inaccessible to remote power management. Some fail within minutes or weeks of installation. These failures occur on many different models, across many generations, and across many hardware vendors. Exposing these failures to users would create a very negative experience, and the cloud must be built to tolerate this complexity.
Focus on the end state
Yahoo’s experience shows that one can run OpenStack at hyperscale, leveraging it to wrap infrastructure and remove perceived complexity. Correctly leveraged, OpenStack presents an easy, consistent, and error-free interface. Delivering this interface is core to our design philosophy as Yahoo continues to double down on our OpenStack investment. The Yahoo OpenStack team looks forward to continue collaborating with the OpenStack community to share feedback and code.