Userspace-Tracing mit DTrace

Als Entwickler habe ich oft das Problem, dass mir auf Produktionssystemen die Sichtbarkeit auf Programminterna fehlt: Wie viele Requests verarbeitet mein Programm gerade pro Sekunde? Ist die Queue aktuell voll?

Nun kann man anfangen, an allen möglichen Stellen Logeinträge zu schreiben. Allerdings wirken sich diese zum einen auf die Performance aus (nichts ist gratis, auch und gerade das Schreiben von Logs nicht) und zum anderen ist es extrem mühsam, die so gesammelten Daten im Anschluss in ein annehmbares Format zu bringen, um wirklich eine Aussage über die Performance treffen zu können. Andere Tools wie rr und valgrind sind dagegen zum Debuggen sehr praktisch, verlangsamen die ausgeführten Programme jedoch extrem, weswegen sie sich nicht für den produktiven Einsatz eignen.

Einen Lösungsansatz bieten hier Tracing-Frameworks. Hierzu liefert das eigene Programm bei bestimmten Ereignissen (z.B. wenn ein Request verarbeitet wurde) strukturierte Daten (z.B. Länge des Requests, Anzahl der Ergebnisse, o.ä.). Diese werden vom Tracing-Framework gesammelt und aufbereitet. Ein solches Framework ist DTrace. Es wurde ursprünglich von Sun Microsystems für Solaris entwickelt, ist allerdings auch für macOS verfügbar. Zudem bietet SystemTap unter Linux Kompatibilität für Teile der DTrace-Infrastruktur.

DTrace erlaubt es, interessante Stellen in den eigenen Programmen mit Probes auszustatten:

provider icinga {
	probe wq__full(void *wq);
	probe wq__starved(void *wq);
	probe wq__task__interleaved(void *wq);
	probe wq__task__begin(void *wq);
	probe wq__task__end(void *wq);
};

Zur Laufzeit des Programms sind diese Probes zunächst nicht aktiv und verursachen keinen Overhead. Dies erlaubt es, Probes auch in Release-Versionen mit auszuliefern, was das Analysieren von Performance-Problemen erleichtert, da nicht erst spezielle Pakete installiert werden müssen.

DTrace kann Probes je nach Bedarf aktivieren und auch wieder deaktivieren, auch wenn das Programm bereits läuft. Auch können Ereignisse mit DTrace-Scripts direkt in Relation zueinander gesetzt werden, um z.B. die Dauer zwischen zwei Ereignissen zu erfassen:

$ cat wq.d
icinga$target:::wq-task-begin
{
	self->ts = timestamp;
}

icinga$target:::wq-task-end
{
	@ = quantize(timestamp - self->ts);
}

Dieses Script können wir nun verwenden, um eine bereits laufende Icinga-Instanz zu analysieren:

$ ps ax | grep icinga2
56711 s003  R+     0:00.00 grep icinga2
56685 s006  R+     0:05.68 /Users/gunnar/i2/lib/icinga2/sbin/icinga2 daemon
56705 s006  S+     0:00.05 /Users/gunnar/i2/lib/icinga2/sbin/icinga2 daemon
$ sudo dtrace -s wq.d -p 56685
dtrace: system integrity protection is on, some features will not be available

dtrace: script 'wq.d' matched 2 probes
^C


           value  ------------- Distribution ------------- count
          524288 |                                         0
         1048576 |@                                        5
         2097152 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@       160
         4194304 |@@@                                      14
         8388608 |                                         1
        16777216 |                                         0
        33554432 |                                         0
        67108864 |                                         0
       134217728 |                                         0
       268435456 |                                         1
       536870912 |@                                        3
      1073741824 |                                         0
      2147483648 |                                         0
      4294967296 |                                         0
      8589934592 |                                         0
     17179869184 |                                         0
     34359738368 |                                         0
     68719476736 |                                         0
    137438953472 |@                                        4
    274877906944 |                                         0

$

Mein Ziel ist es, in absehbarer Zeit in Icinga 2 offiziell Support für DTrace einzubauen. Mal schauen, was sich damit dann alles rausfinden lässt. 🙂

Gunnar Beutner

Autor: Gunnar Beutner

Vor seinem Eintritt bei NETWAYS arbeitete Gunnar bei einem großen deutschen Hostingprovider, wo er bereits viel Erfahrung in der Softwareentwicklung für das Servermanagement sammeln konnte. Bei uns kümmert er sich vor allem um verschiedene Kundenprojekte, aber auch eigene Tools wie inGraph oder Icinga2.

Modern open source community platforms with Discourse

Investing into open source communities is key here at NETWAYS. We do a lot of things in the open, encourage users with open source trainings and also be part of many communities with help and code, be it Icinga, Puppet, Elastic, Graylog, etc.

Open source with additional business services as we love and do only works if the community is strong, and pushes your project to the next level. Then it is totally ok to say “I don’t have the time to investigate on your problem now, how about some remote support from professionals?”. Still, this requires a civil discussion platform where such conversations can evolve.

One key factor of an open source community is to encourage users to learn from you. Show them your appreciation and they will like it and start helping others as you do. Be a role model and help others on a technical level, that’s my definition of a community manager. Add ideas and propose changes and new things. Invest time and make things easier for your community.

I’ve been building a new platform for monitoring-portal.org based on Discourse in the last couple of days. The old platform based on Woltlab was old-fashioned, hard to maintain, and it wasn’t easy to help everyone. It also was closed source with an extra license, so feature requests were hard for an open source guy like me.

Discourse on the other hand is 100% open source, has ~24k Github stars and a helping community. It has been created by the inventors of StackOverflow, building a conversation platform for the next decade. Is is fast, modern, beautiful and both easy to install and use.

 

Setup as Container

Discourse only supports running inside Docker. The simplest approach is to build everything into one container, but one can split this up too. Since I am just a beginner, I decided to go for the simple all-in-one solution. Last week I was already using the 1.9.0beta17, running really stable. Today they released 1.9.0, I’ll share some of the fancy things below already 🙂

Start on a fresh VM where no applications are listening on port 80/443. You’ll also need to have a mail server around which accepts mails via SMTP. Docker must be installed in the latest version from the Docker repos, don’t use what the distribution provides (Ubuntu 14.04 LTS here).

mkdir /var/discourse
 
git clone https://github.com/discourse/discourse_docker.git /var/discourse

cd /var/discourse
./discourse-setup

The setup wizard ask several questions to configure the basic setup. I’ve chosen to use monitoring-portal.org as hostname, and provided my SMTP server host and credentials. I’ve also set my personal mail address as contact. Once everything succeeds, the configuration is stored in /var/discourse/container/app.yml.

 

Nginx Proxy

My requirement was to not only serve Discourse at /, but also have redirects for other web applications (the old Woltlab based forum for example). Furthermore I want to configure the SSL certificates in a central place. Therefore I’ve been following the instructions to connect Discourse to a unix socket via Nginx.

apt-get install nginx

rm /etc/nginx/sites-enabled/default

vim /etc/nginx/sites-available/proxy.conf
server {
    listen 443 ssl;  listen [::]:443 ssl;
    server_name fqdn.com;

    ssl on;
    ssl_certificate      /etc/nginx/ssl/fqdn.com-bundle.crt;
    ssl_certificate_key  /etc/nginx/ssl/fqdn.com.key;

    ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA;
    ssl_prefer_server_ciphers on;

    # openssl dhparam -out /etc/nginx/ssl/dhparam.pem 4096
    ssl_dhparam /etc/nginx/ssl/dhparam.pem;

    # OCSP Stapling ---
    # fetch OCSP records from URL in ssl_certificate and cache them
    ssl_stapling on;
    ssl_stapling_verify on;

    location / {
        error_page 502 =502 /errorpages/discourse_offline.html;
        proxy_intercept_errors on;
        # Requires containers/app.yml to use websockets
        proxy_pass http://unix:/var/discourse/shared/standalone/nginx.http.sock:;
        proxy_set_header Host $http_host;
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }
}
ln -s /etc/nginx/sites-available/proxy.conf /etc/nginx/sites-enabled/proxy.conf
 
service nginx restart

Another bonus of such a proxy is to have a maintenance page without an ugly gateway error.

The full configuration can be found here.

 

Plugins

Installation is a breeze – just add the installation calls into the app.yml file and rebuild the container.

# egrep -v "^$|#" /var/discourse/containers/app.yml
templates:
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"
  - "templates/web.ratelimited.template.yml"
expose:
params:
  db_default_text_search_config: "pg_catalog.english"
env:
  LANG: en_US.UTF-8
  DISCOURSE_HOSTNAME: fqdn.com
  DISCOURSE_DEVELOPER_EMAILS: 'contact@fqdn.com'
  DISCOURSE_SMTP_ADDRESS: smtp.fqdn.com
  DISCOURSE_SMTP_PORT: 587
  DISCOURSE_SMTP_USER_NAME: xxx
  DISCOURSE_SMTP_PASSWORD: xxx
volumes:
  - volume:
      host: /var/discourse/shared/standalone
      guest: /shared
  - volume:
      host: /var/discourse/shared/standalone/log/var-log
      guest: /var/log
hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/discourse/docker_manager.git
          - git clone https://github.com/discourse/discourse-akismet.git
          - git clone https://github.com/discourse/discourse-solved.git
run:
  - exec: echo "Beginning of custom commands"
  - exec: echo "End of custom commands"

./launcher rebuild app

Akismet checks against spam posts as you know it from WordPress. We’ve learned that spammers easily crack reCaptcha, and the only reliable way is filtering the actual posts.

The second useful plugin is for accepting an answer in a topic, marking it as solved. This is really useful if your platform is primarily used for Q&A topics.

 

Getting Started

Once everything is up and running, navigate to your domain in your browser. The simple setup wizard greets you with some basic questions. Proceed as you like, and then you are ready to build the platform for your own needs.

The admin interface has lots of options. Don’t fear it – many of the default settings are from best practices, and you can always restore them if you made a mistake. There’s also a filter to only list overridden options 🙂

Categories and Tags

Some organisation and structure is needed. The old-fashioned way of choosing a sub forum and adding a topic in there is gone. Still Discourse offers you to require a category from users. Think of monitoring – a question on the Icinga Director should be highlighted in a specific category to allow others to catch up.

By the way – you can subscribe to notifications for a specific category. This helps to keep track only for Icinga related categories for example.

In addition to that, tags help to refine the topics and make them easier to search for.

Communication matters

There are so many goodies. First off, you can start a new topic just from the start page. An overlay page which saves the session (!) is here for you to edit. Start typing Markdown, and see it pre-rendered live on the right side.

You can upload images, or paste an URL. Discourse will trigger a job to download this later and use a local cache. This avoids broken images in the future. If you paste a web link, Discourse tries to render a preview in “onebox”. This also renders Github URLs with code preview.

Add emotions to your discussion, appreciate posts by others and like them, enjoy the conversation and share it online. You can even save your draft and edit it amongst different sessions, e.g. after going home.

 

Tutorials, Trust Level and Rewards

Once you register a new account (you can add oauth apps from Twitter, Github, etc.!), a learning bot greets you. This interactive tutorial helps you learning the basics with likes, quotes, urls, uploads, and rewards you with a nice certificate in the end.

New users don’t start with full permissions, they need to earn their trust. Once they proceed with engaging with the community, their trust level is raised. The idea behind this is not to have moderators and admins regulating the conversation, but let experienced members to it. Sort of self healing if something goes wrong.

Users who really engage and help are able to earn so-called badges. These nifty rewards are highlighted on their profile page, e.g. for likes, number of replies, shared topics, even accepted solutions for questions. A pure motivation plaything built into this nice piece of open source software.

 

Wiki and Solved Topics

You can change topics to wiki entries. Everyone can edit them, this way you’ll combine the easiness of writing things in Markdown with a full-blown documentation wiki.

Accepting a replay as solution marks a topic as “solved”. This is incredibly helpful for others who had the same problem.

 

Development

As an administrator, you’ll get automated page profiling for free. This includes explained SQL queries, measured page load time, and even flame graphs.

If you ever need to reschedule a job, e.g. for daily badge creation, admins can access the Sidekiq web UI which really is just awesome.

Plugin development seems also easy if you know Ruby and EmberJS. There are many official plugins around which tested before each release.

Discourse also has a rich REST API. Even a monitoring endpoint.

 

Maintenance

You can create backups on-demand in addition to regular intervals. You can even restore an old backup directly from the UI.

 

Conclusion

Discourse is used by many communities all over the world – Graylog, Elastic, Gitlab, Docker, Grafana, … have chosen to use the power of a great discussion platform. So does monitoring-portal.org as a #monitoringlove community. A huge thank you to the Discourse team, your software is pure magic and just awesome 🙂

My journey in building a new community forum from scratch in just 5 days can be read here 🙂

monitoring-portal.org running Discourse is fully hosted at NETWAYS, including SSL certificates, Puppet deployment and Icinga for monitoring. Everything I need to build an awesome community platform. You too?

 

Michael Friedrich

Autor: Michael Friedrich

Michael ist seit vielen Jahren Icinga Developer und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht im Monitoring-Portal helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst das schöne Nürnberg. Oder - at an Icinga Camp near you 😉

Über Microservices und Jabberbots

Bei unserer Unternehmensfortbildung am 30. November und 1. Dezember haben wir in kleineren Gruppen an diversen Projekten gearbeitet. Eines der Themen war die Integration unserer intern verwendeten Services (Wiki, Ticketsystem, u.ä.) in einen Jabberbot. Davon versprechen wir uns, dass häufig genutzte Tasks automatisiert werden können, wie etwa:

  • Nach Kunden im CRM suchen, um diese beispielsweise schnell und einfach anrufen zu können.
  • Im Ticketsystem Tickets kommentieren oder schließen.
  • In der Zeiterfassung Zeit auf bestimmte Projekte buchen.

Dass sich über Jabber nicht alle Features der darunter liegenden Tools abbilden lassen, war uns dabei von Anfang an bewusst und sollte auch gar nicht Ziel des Bots sein.

Eine weitere grundsätzliche Herausforderung besteht darin, die abgefragten Informationen so aufzubereiten, dass sie vom Benutzer verwendet werden können. Im Gegensatz zu einer Webseite bietet Jabber nur sehr eingeschränkte Möglichkeiten, Text zu formatieren und zwischen Informationen zu verlinken. Unser Bot wird sich daher auf das wesentliche beschränken müssen. Bei Tickets können so etwa nur die Betreffzeile und einige weitere ausgewählte Attribute angezeigt werden. Wer mehr braucht, gelangt über einen Link zum vollständigen Ticket – im Browser.

Um auch anderen Mitarbeitern die Möglichkeit zu geben, eigene Services in den Bot zu integrieren, haben wir uns nach einer kleinen Architekturphase dazu entschieden, dass der Bot an sich keinerlei eigene Funktionalität beinhaltet, sondern alle seine Befehle an eine Reihe von Microservices delegiert. Diese sollen über eine REST-Schnittstelle angesprochen werden und ihren eigenen Funktionsumfang selbst beschreiben können. Dies ermöglicht dem Bot, beliebige Services zu integrieren, ohne diese im Vorfeld kennen zu müssen. Unsere Benutzer sollen die Möglichkeit haben, für ihren Account eigene Services anhand einer HTTP-URL hinzuzufügen. Der Vorteil hiervon ist, dass jeder spielerisch eigene Services entwickeln und aktivieren kann, ohne über unser Sysadmin-Team Module beim Bot neuladen lassen zu müssen. Auch können Programmierfehler (sleep() im Modul, o.ä.) nicht die Stabilität des Bots gefährden.

Soweit unsere aktuelle Idee. Es gibt zwar auch schon einen sehr frühen Prototypen (auf Basis von errbot), der auch bereits externe Services verwenden kann. Allerdings fehlen auch noch viele Sachen, allen voran natürlich tatsächliche Services für viele unserer Tools. Ich bin aber zuversichtlich, dass wir mit vergleichsweise wenig Entwicklungsaufwand einen einsatzfähigen Bot basteln können. Hoffentlich gibt es dazu dann einmal ein Update inkl. Sourcecode, wenn dies soweit ist.

Gunnar Beutner

Autor: Gunnar Beutner

Vor seinem Eintritt bei NETWAYS arbeitete Gunnar bei einem großen deutschen Hostingprovider, wo er bereits viel Erfahrung in der Softwareentwicklung für das Servermanagement sammeln konnte. Bei uns kümmert er sich vor allem um verschiedene Kundenprojekte, aber auch eigene Tools wie inGraph oder Icinga2.

Override Vagrant Config Locally

We are using Vagrant for most of our projects in order to provide the work environment for all people involved in the project. One of the things that we think is missing, is the option to easily override the Vagrant config locally. Developers could of course just change the Vagrantfile but this is not quite handy if it is managed via Git for example. Recently we came across the idea to include a local Vagrantfile if it exists:

Vagrant.configure("2") do |config|
  #
  # ...
  #

  if File.exists?(".Vagrantfile.local") then
    eval(IO.read(".Vagrantfile.local"), binding)
  end
end

This allows us to extend or override any Vagrant config in the file .Vagrantfile.local which developers exclude from Git. If you want to add a synced folder for example, the file could look like the following:

config.vm.synced_folder "../icingaweb2-module-director",
  "/usr/share/icingaweb2-modules/director"

config.vm.synced_folder "../icingaweb2-module-businessprocess",
  "/usr/share/icingaweb2-modules/businessprocess"
Eric Lippmann

Autor: Eric Lippmann

Eric kam während seines ersten Lehrjahres zu NETWAYS und hat seine Ausbildung bereits 2011 sehr erfolgreich abgeschlossen. Seit Beginn arbeitet er in der Softwareentwicklung und dort an den unterschiedlichen NETWAYS Open Source Lösungen, insbesondere inGraph und im Icinga Team an Icinga Web. Darüber hinaus zeichnet er sich für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.

Monthly Snap November > OSMC 2017, OSDC 2018, Puppet, GitLab EE, Icinga 2, NETWAYS Startupdays, Visual Studio 2017

In November, we had our international Open Source Monitoring Conference where Markus announced the last tickets for. Julia blogged live OSMC news, and Michael explained how to replace spaces with tabs in Visual Studio 2017, while Dirk told us about Custom Datatypes in Puppet.

Nicole always brings something interesting every month, this time she showed some NETWAYS Web Services: GitLab EE and connect to your own Domain!. Noah explained Icinga 2 – CA Proxy, Christoph brought some creative stuff in “Unusual Surveillances” and Isabel shared some news on the SMSEagle.

Later in November, Dirk shared his impressions of OSMC day 1 and 2 as well as the news from the Hackathon on the last day of OSMC. Keya announced the Call for Papers for the Open Source Data Center Conference and last but not least, Philipp shared exciting news from the NETWAYS Startupdays, before the Christmas month at NETWAYS starts.

Keya Kher

Autor: Keya Kher

Keya hat im Oktober ihr Praktikum im Marketing bei NETWAYS gestartet. Letzten Dezember startete Sie gemeinsam mit Ihrem Mann das “Abenteuer Deutschland”. Seitdem lernt Sie fleißig deutsch und fühlt sich bei NETWAYS schon jetzt pudelwohl. Sie hat schon viele Erfahrungen im Social Media Marketing und ist gerade dabei auch im Grafikdesign ein Profi zu werden. Wenn sie nicht gerade dabei ist, sich kreativ auszuleben, entdeckt sie die Stadt und schmökert gerne im ein oder anderen Büchlein. Ihr Favorit ist hierbei “The Shiva Trilogy”.

NETWAYS Web Services: GitLab EE

This entry is part 2 of 10 in the series NETWAYS Web Services

The NETWAYS Web Services Team is proud to announce the arrival of a new product: Customers can now have their GitLab EE instances hosted on our NWS platform.

Version control has become one of the most important aspects of everyday work life and has gone far beyond being only used by development teams. Many more use cases for version control have been created so far and are still to come. Even small teams are already using GitLab CE for controlling their workflows which is one of our reasons to offer this software as a hosted product.

After realizing that many users needed higher performance for increasing their productivity, we decided to add GitLab EE to our portofolio as it offers many more options and features than the CE version – without having to take care of the underlying hard- and software layers needed for running the application.

The process of hosting GitLab EE with us is almost as simple and comfortable as with all our other products – create an NWS account, choose a product and get started. GitLab EE makes a little exception for it is an Enterprise product and therefore customers need to provide a license acquired at GitLab. You can be sure that all features included in your license will be available in your NWS container right from the start.

This license is the only aspect the customer needs to take care of – NWS will provide all the comfort our customers already know from our other products, like maintenance works, updates, patches and a stable and well monitored platform underneath.

 

All those who do not want to worry about their version control should take a look at our attractive and scalable plans as well as individually sized solutions for hosting GitLab EE. More information can be found on our NWS homepage, in our GitLab EE section or by contacting us via the NWS livechat.

Important note: All NWS products are up for a 30 day free trial!

 

Nicole Lang

Autor: Nicole Lang

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest Bücher und zockt auch mal gerne.