 |
4th - 5th February Brussels | FOSDEM 2012 - Who Pulls the Strings? Integrating OpenNMS with Modern Configuration Management | Talk in Configuration and Systems Management Devroom with OGP mates Jeff Gehlbach and Jason Aras |
|---|
So mittlerweile bin ich wieder zu Hause und erholt von zwei interessanten Tagen in Nürnberg auf der OSMC 2011. Ganz besondere Grüße an dieser Stelle gehen an die anderen aussässigen Sprecher: Reinhard Scheck mit Cacti, Remo Rickli mit NeDI, Dr. Michael Schwartzkopff mit SNMPv3, Georg Kostner mit Syslog, Roland Huß mit Jolokai und Sebastian Harl mit collectd. Vielen Dank dass ihr das doch recht Icinga und Nagios lastige Programm aufgelockert habt. Von 23 Vorträgen inklusive der Begrüssung gab es 7 Vorträge die nichts mit Nagios oder einem Nagios-Fork zu tun hatten ;) Die Highlights für mich auf der Programmliste waren:
Ich hatte schon einmal das Vergnügen in Forschungsprojekten mitzuarbeiten. Dabei ging es auch um die Leistungsfähigkeit von Open-Source Monitoringanwendungen. Daher habe ich mich auf den Performance-Vergleich von Nagios, Icinga und Shinken besonders gefreut. Zudem war ich gespannt wie sich die beiden Forks Shinken und Icinga auf die Leistungsfähigkeit auswirken. Einer der Hauptkritikpunkte der beiden Forks war ja schliesslich, dass im Nagios Core nur schwer oder keine Veränderungen gemacht werden konnten. Es hat mich und vermutlich wie auch viele andere brennend interessiert ob sich die zwei Jahre fork() positiv auf Shinken und den Icinga Core ausgewirkt haben.
Beim Test der Scheduler in Nagios und Icinga waren "leider" keine Unterschiede festzustellen. Es wurde eine Simulation mit bis zu 60.000 "Checks" und zufällig schwankenden Ausführzeiten beschrieben. Der Code der Scheduler wurde in der Ausarbeitung nicht betrachtet. Nagios als auch Icinga zeigten bei der Präsentation ein ähnliches nahezu "gleiches" Verhalten. Shinken hat eine lose gekoppelte Architektur im Kern und zeigte eine wesentlich besseres Verhalten. Damit das ganze für alle drei Tools noch vergleichbar bleibt wurde der Performancevergleich dann mit Nagios + mod_gearman und Icinga + mod_gearman weitergeführt. "Gearman" ist eine eigenständiges Open Source Projekt und stellt eine API bereit um Anwendungen zu verteilen – "Nagios/Icinga-on-Steroids".
Das Ergebnis war wenig verwunderlich, Nagios/Icinga hatten das gleiche Verhalten und waren am Ende, was die Latenz-Zeiten angeht, einen Tick besser als Shinken. Vermutlich ist hier tatsächlich ein kleiner Vorteil der C-Implementierung des Nagios-Core gegenüber Python zu sehen – but who knows. Das Ergebnis, dass die Check-Latenz über der Zeit linear ansteigt würde ich mit einfachen Vermutungen bezweifeln. Die Beschreibung der Skalierbarkeit der Scheduler mit der "Check-Latenz" über der Zeit mit der "Big-O Notation" zu beschreiben halte ich persönlich für gewagt. Laut meinem Verständnis sagt mir die O-Notation in der Informatik etwas über die Effizienz von Algorithmen aus, der Code der Scheduler wurde dabei ja bewusst NICHT analysiert – ich lasse mich aber an dieser Stelle gerne eines besseren belehren. Das fork() aufwändiger ist als Thread spawn oder gar Thread Pools ist eigentlich klar – von daher war ich ein wenig enttäuscht, kritische Objektivität hätte ich mir gewünscht. Ich bin wohl zu viele Barcamps und freie Konferenzen im c4fd Umfeld gewohnt ;)
Der einzige fork() der den Kern von Nagios überarbeitet hat ist meiner Ansicht nach Shinken. Sie haben durch eine komplette Reimplementierung in Python Schwächen bei der Skalierung durch eine andere Architektur angepeilt. Das ganze wurde damit für mich eigentlich erst auf den zweiten Blick deutlich. Was den Inhalt angeht, waren vermutlich meine persönlichen Erwartungen etwas zu hoch, da ich mich mit diesem Thema schon beschäftigt habe.
Bei dem Vortrag "Monitoring at large" wurde dargestellt welche Ideen im Icinga Projekt stecken um das Thema Verteilbarkeit und Skalierbarkeit besser zu adressieren. Vorallem das Thema Queuing mit ZeroMQ scheint einiges an Potential zu verbergen. Im Thema SLA Reporting ging es letztendlich darum wie man die Daten aus einem Icinga Availability Report "parst" und in MySQL und JasperReports auswertet. Ich dachte ich kann mir da an der Stelle etwas abgucken was ich OpenNMS verwenden kann, da war aber nix für mich dabei :) Den Vortrag zu Collectd war sehr interessant und wirklich ausführlich dargestellt. Da in OpenNMS eine ähnliche Implementierung der Datacollection hat, sind die Problemdomänen hier identisch. Jörg Linge hat zudem seinen erfolgreichen "Grapher" PNP4Nagios vorgestellt. So wie ich es verstanden habe, hat der wohl bis jetzt schon so einige Remake Versuche überlebt. Kleiner Tipp, das Projekte einfach in PNP4${fork} umbenennen, dann wird es vermutlich einfacher ;)
Mit Jolokia hat sich noch ein weiteres Projekt vorgestellt, welches sich dem interessanten Thema Java Monitoring annimmt. In dem Vortrag wurde kurz vorgestellt welche Probleme mit JSR-160 und JMX im Monitoring-Umfeld auftreten können. Jolokia schafft hier Abhilfe und stellt einen "einfach" erreichbaren JMX Proxy in die JVM. Das ganze ist unabhängig von der eingesetzten Monitoring-Lösung und damit auf jeden fall einen Blick wert, für alle die sich wie ich in J-Land aufhalten.
Ansonsten kann man grob zusammengefasst sagen, dass das Thema in Richtung mehr "Checks", mehr "Services" geht und wie man das mit Steroiden wie Gearman und ZeroMQ, erreichen kann. Um die CIO`s Happy zu machen ist gerade JasperReports der "Heiße Scheiß". Kann ich ja in einer gewissen Weise auch gut verstehen :) Für mich ist auf jeden Fall Shinken, NeDi und Collectd weiter unter Beobachtung. Icinga gibt mit InGraph ziemlich Vollgas was die Web UI angeht. Das Thema Skalierbarkeit ist meines erachtens momentan mit einem haufen Ideen in der Findungsphase. Bei dem Thema SLA-Reporting bin ich wohl erstmal auf mich alleine gestellt ;) Allen in allem war es eine wirklich angenehme und entspannte Atmosphäre. Die Organisation war absolut perfekt. Man merkt, dass das NETWAYS Team gut eingespielt ist. Ich bedanke mich bei den Organisatoren für die gelungene Konferenz, den regen Erfahrungsaustausch und dass ich die Gelegenheit hatte viele Menschen mit einem Vortrag zu OpenNMS zu quälen ;)
So Long, and Thanks for All the Fish
Links zum Thema:
So bald ist es wieder soweit, Die NOP 2011 findet im N-Gebäude Hochschule Fulda statt. Die NOP ist eine freie und absolut unkommerzielle Veranstaltung. Studentinnen und Studenten sollen dazu animieren werden Themen oder Projekte vorzustellen, die Sie besonders interessieren. Auf der letzten NOP waren einige sehr coole Projekte aus den Fachbereichen der Elektrotechnik und Informatik zu bestaunen die neben dem Studium enstanden sind. Ich hab die extrem entspannte Atmosphäre genossen und werde auf jeden Fall wieder dabei sein. Die aktuellen Themen sehen momentan wie folgt aus:
An Ständen werden die folgenden Projekte vorgestellt:
Wer interesse hat, findet noch ganz viel mehr Informationen auf der offiziellen Website bei http://nop.hs-fulda.org
Ich kann es einfach nicht verstehen warum es so kompliziert ist Microsoft Windows Systeme mit freien Netzwerk Management Tools zu monitoren. Ich habe hier gerade ein Netzwerk mit knapp 50 Windows 7 Enterprise x64 Betriebssystemen vor mir. Ich habe mich aus diesem Grund mit dem Thema Windows Management Instrumentation (WMI) auseinandergesetzt. Als allererstes ist mir aufgefallen, dass WMI standardmässig remote nicht aufrufbar ist. Es hat mich einiges Registry-gefrickel, DCOM Konfigurationsgeklicke und Nerven gekostet bis ich WMI von einem entfernten Server abfragen konnte. Ich kann jedem Leidensgenossen das Troubleshooting WMI Dokument der Spiceworks Community ans Herz legen – dickes DANKE! Mit diesem Dokument hat man eine echte Chance WMI und OpenNMS konfiguriert zu bekommen.
Das ganze Thema ist in OpenNMS recht unspektakulär. In der Datei wmi-config.xml muss die Authentifizierung eingetragen werden:
<?xml version="1.0"?> <wmi-config retry="2" timeout="1500" username="${login}" domain="${workgroup}" password="${pass}"> </wmi-config>
${OPENNMS_HOME}/bin zum testen her nehmen.checkwmi -matchType all -wmiClass Win32_BIOS -wmiObject Status -op EQ -value OK -domain . ${ip} ${login} ${pass}
Checking: for Status Op: EQ Val: OK Check results: OK (1) Result for (1) Win32_BIOS\Status: OK
Den Detector habe ich für meine Provisioning Group wie folgt angelegt:
<detector class="org.opennms.netmgt.provision.detector.wmi.WmiDetector" name="WMI-BIOS-Status"> <parameter value="Win32_BIOS" key="wmiClass"/> <parameter value="EQ" key="compOp"/> <parameter value="OK" key="compVal"/> <parameter value="Status" key="wmiObject"/> <parameter value="WMI-BIOS-Status" key="serviceName"/> </detector>
poller-configuration.xml wie folgt aus:<service name="WMI-BIOS-Status" interval="300000" user-defined="false" status="on"> <parameter key="retry" value="2"/> <parameter key="timeout" value="3000"/> <parameter key="matchType" value="all"/> <parameter key="wmiClass" value="Win32_BIOS"/> <parameter key="wmiObject" value="Status"/> <parameter key="compareOp" value="EQ"/> <parameter key="compareValue" value="OK"/> <parameter key="service-name" value="WMI-BIOS-Status"/> </service> . <monitor service="WMI-BIOS-Status" class-name="org.opennms.netmgt.poller.monitors.WmiMonitor"/>
collectd-configuration.xml für den WMI-BIOS-Status die WMI-Datacollection. Wichtig! Darauf achten, dass der status="on" gesetzt ist. WMI ist standardmäßig deaktiviert.
<service name="WMI-BIOS-Status" interval="300000" user-defined="false" status="on"> <parameter key="collection" value="default"/> <parameter key="thresholding-enabled" value="true"/> </service> . <collector service="WMI-BIOS-Status" class-name="org.opennms.netmgt.collectd.WmiCollector"/>
Nach dem beherzten Neustart von OpenNMS sollten jetzt regelmäßig die Leistungsdaten für WMI eintrudeln und hübsche RRD Graphen generieren.
Die Überwachung von Windows Diensten lässt sich jetzt ebenfalls sehr komfortabel umsetzen. Ein Monitor für die Überwachung von Microsoft SQL Server Diensten würde dann beispielsweise so aussehen:
Detector Konfiguration:
<detector class="org.opennms.netmgt.provision.detector.wmi.WmiDetector" name="WMI-SQL-Server"> <parameter value="Select State From Win32_Service Where DisplayName='SQL Server (MSSQLSERVER)'" key="wmiWqlStr"/> <parameter value="State" key="wmiObject"/> <parameter value="EQ" key="compOp"/> <parameter value="Running" key="compVal"/> <parameter value="WMI-SQL-Server" key="serviceName"/> </detector> <detector class="org.opennms.netmgt.provision.detector.wmi.WmiDetector" name="WMI-SQL-Server-Browser"> <parameter value="Select State From Win32_Service Where DisplayName='SQL Server-Browser'" key="wmiWqlStr"/> <parameter value="State" key="wmiObject"/> <parameter value="EQ" key="compOp"/> <parameter value="Running" key="compVal"/> <parameter value="WMI-SQL-Server-Browser" key="serviceName"/> </detector> <detector class="org.opennms.netmgt.provision.detector.wmi.WmiDetector" name="WMI-SQL-Server-VSS-Writer"> <parameter value="Select State From Win32_Service Where DisplayName='SQL Server VSS Writer'" key="wmiWqlStr"/> <parameter value="State" key="wmiObject"/> <parameter value="EQ" key="compOp"/> <parameter value="Running" key="compVal"/> <parameter value="WMI-SQL-Server-VSS-Writer" key="serviceName"/> </detector>
Die Konfiguration für die Monitore sieht in der poller-configuration.xml dann wie folgt aus:
<service name="WMI-SQL-Server" interval="300000" user-defined="false" status="on"> <parameter key="retry" value="2"/> <parameter key="timeout" value="3000"/> <parameter key="matchType" value="all"/> <parameter key="wql" value="Select State From Win32_Service Where DisplayName='SQL Server (MSSQLSERVER)'"/> <parameter key="wmiObject" value="State"/> <parameter key="compareOp" value="EQ"/> <parameter key="compareValue" value="Running"/> <parameter key="service-name" value="WMI-SQL-Server"/> </service> <service name="WMI-SQL-Server-Browser" interval="300000" user-defined="false" status="on"> <parameter key="retry" value="2"/> <parameter key="timeout" value="3000"/> <parameter key="matchType" value="all"/> <parameter key="wql" value="Select State From Win32_Service Where DisplayName='SQL Server-Browser'"/> <parameter key="wmiObject" value="State"/> <parameter key="compareOp" value="EQ"/> <parameter key="compareValue" value="Running"/> <parameter key="service-name" value="WMI-SQL-Server-Browser"/> </service> <service name="WMI-SQL-Server-VSS-Writer" interval="300000" user-defined="false" status="on"> <parameter key="retry" value="2"/> <parameter key="timeout" value="3000"/> <parameter key="matchType" value="all"/> <parameter key="wql" value="Select State From Win32_Service Where DisplayName='SQL Server VSS Writer'"/> <parameter key="wmiObject" value="State"/> <parameter key="compareOp" value="EQ"/> <parameter key="compareValue" value="Running"/> <parameter key="service-name" value="WMI-SQL-Server-VSS-Writer"/> </service> . <monitor service="WMI-SQL-Server" class-name="org.opennms.netmgt.poller.monitors.WmiMonitor"/> <monitor service="WMI-SQL-Server-Browser" class-name="org.opennms.netmgt.poller.monitors.WmiMonitor"/> <monitor service="WMI-SQL-Server-VSS-Writer" class-name="org.opennms.netmgt.poller.monitors.WmiMonitor"/>
Der Test von der Kommandozeile mit WQL kann wie folgt getestet werden:
checkwmi -matchType all -wmiWql "Select State From Win32_Service Where DisplayName='SQL Server (MSSQLSERVER)'" -wmiObject State -op EQ -value Running -domain . ${ip} ${login} ${pass}
Die Ausgabe Check results: OK (1) zeigt an dass der Monitor den Status Running zurückliefert.
Prinzipiell bin ich ja echt glücklich, dass Windows sich mit WMI und OpenNMS überwachen lässt. Der erste Pferdefuß kommt allerdings mit Exchange 2007. Dort wurden die WMI Provider nicht mehr implementiert. Alles jenseits Microsoft Exchange 2007 muss mit PowerShell administriert werden. Sorry das ist wieder einmal ein gutes Beispiel für die Kategorie – Proprietäre Managementprotokolle sind beschissen.
Vom zweiten Pferdefuß werden nur die getroffen, die in großen Windows-Umgebungen arbeiten. Die Skalierbarkeit mit WMI ist deutlich eingeschränkt. Wenn man massiv viele Dienste und Leistungsdaten mit WMI überwacht, fällt einem zuerst die große Anzahl von TCP Sessions pro Sekunde und offenen TCP Connections auf dem OpenNMS Server auf. Zusätzlich hat bei mir der Einsatz von WMI gezeigt, dass ich auf dem OpenNMS Server wesentlich mehr Netzwerktraffic sehe.
Das alles hat mich neugierig gemacht und ich habe mir den Verkehr angesehen, der auftritt wenn man den BIOS-Status mit checkwmi abfragt. Das Ergebnis spricht für sich selbst:
Der Kringel da in der Mitte ist übrigens der Request und Response auf den es eigentlich angkommt. Wer also extrem viele Windows Server hat und die Dienste über WMI monitoren will, der braucht echt viel Dampf unter der Haube. Es werden viele Ressourcen für den Verbindungsaufgbau (NTLM-Dialect-Aushandlungs-und-SMB-Session-establishment-Kung-Fu) gebraucht. Eine einzige erfolgreiche Abfrage belegt für knapp 1,6 Sekunden Ressourcen auf dem OpenNMS Server. Ich weiss ich kann mir das sparen aber so sieht das bei einem SNMP Get aus. Von der Zeit brauchen wir nicht reden:
Momentan überwache ich 1098 Dienste und sammle ~4800 Leistungsdaten per WMI ein. Der OpenNMS Server hat damit durchschnittlich 4Mbit/s ein- und ausgehend gemittelt auf 5 Minuten – Echt ein haufen Holz für so eine Spielzeugumgebung.
So long ...
Es wurde wieder einmal Zeit die Virtual Appliance von OpenNMS zu aktualisieren. Neben dem Image für VMware existiert jetzt ebenfalls ein OVA template. Damit sollte einem Einsatz in Virtual Box oder anderen offenen Virtualisierungs-Programmen nichts im Wege stehen. Das Image enthält:
Linksammlung:
Für die Jungs die AKCP Geräte im Einsatz haben, können sich über native Unterstützung der SecurityProbes freuen.
So long ...
Sorry damit ist nicht MAP08 in Doom II gemeint. Ich arbeite hauptsächlich mit Sysadmins zusammen und bekomme hin und wieder die Frage gestellt: "Was ist ein SNMP Inform?"
Ok um das ganze grundlegend zu beleuchten beginnen wir da, wo Dinge beginnen. "Es war einmal ein ..." ok, ok ich fang anders an. Wie wir alle wissen gibt es zwei Möglichkeiten rauszukriegen ob irgendetwas noch so läuft wie es läuft:
Stellen wir uns einmal vor, eine Arztpraxis kommt auf die Idee auf Polling umzustellen? Ich glaube wir wären relativ schnell genervt und wir können nur hoffen, dass die ne Telefon-Flat und eine leidensfähige Sekretärin haben :) Wir als unbescholtene, brave Bürger sind also eher Ereignis getrieben und gehen dann zum Arzt, wenn es uns schlecht geht oder wir keinen Urla ... äh ok nein lassen wir das. Polling kann also nervig sein ganz ohne gehts aber auch nicht. Wenn sich jetzt jemand zuhause die Füsse bricht und vorm Kühlschrank rumliegt, hat er ziemlich viel Glück. Schliesslich hat er was zu essen und kaltes Bier vor der Nase. Zum Arzt gehen kann er dann nicht mehr, Onkel Doc denkt alles ist super und hat die Füsse auf dem Schreibtisch – isses ja auch zumindest so lange das Bier noch reicht. Es kann also von Vorteil sein, dass ab und an mal jemand vorbeikommt, auch auf die Gefahr hin, dass man sein Bier teilen muss – das aber nur am Rande.
Wie uns also der gesunde Menschenverstand mitteilt, hört sich die erste Variante irgendwie aufwändig an. Zwischen extrem lose gekoppelten Systemen – also so lose gekoppelt dass die voneinander überhaupt nichts wissen, ist häufig ausser Polling überhaupt nichts anderes möglich. Bei Netzwerkkomponenten ist das leider häufig so. Damit sich Geräte verwalten lassen hat man sich SNMP überlegt. Der Teil der im Router steckt ist ein SNMP Agent und das was der Sysadmin bei sich installiert um seine Netzwerkgeräte zu überwachen und zu verwalten nennt man Network Management Station (NMS). Anmerkung: Die Abkürzung NMS ist ziemlich überstrapaziert. Häufig versteht man NMS auch als Netzwerk Management System.
Bei der Einführung von SNMP in den 80er Jahren wurden glücklicherweise beide Prinzipien berücksichtigt. Mit unseren tollen Monitoring und Management-Anwendungen können wir jetzt also nach belieben SNMP Agenten "pollen" oder lassen uns bei Bedarf Fehler oder Statusinformationen ereignisorientiert senden - SNMP Traps. Spitze dann ist ja alles super und wir können einpacken und heim gehen ...
... leider nein. SNMP kommuniziert verbindungslos und unbestätigt über UDP. Das bedeutet der SNMP Agent in einem Router kümmert sich also einen Dreck ob die Nachricht auch wirklich beim NMS angekommen ist. Man könnte das Prinzip auch Fire and Forget bezeichnen.
In der IP-Welt könnten wir auf die Idee kommen einen Trap doch einfach per TCP zu versenden – das ganze ist dann verbindungsorientiert und bestätigt. Die Verbindung wird über einen 3-Wege-Handshake aufgebaut, der Trap wird mit bestätigten TCP-Segementen versendet und danach wird die Verbindung abgebaut. Wenn es dem Gerät beschissen geht, dann könnte es möglich sein, dass die Verbindungsverwaltung und Bestätigungen nicht vernünftig organisiert werden kann und es kommt gar keine Kommunikation zu stande. Man braucht also was schlankeres.
Seit SNMPv2 gibt es neben den SNMP Traps – die mit einer Ladung Hoffnung versendet werden – nun SNMP Informs. SNMP Informs sind bestätigte SNMP Traps – WTF? Ein SNMP Agent sendet einen SNMP Inform (InformRequest) an eine NMS. Damit der Agent sicher weiss, dass der InformRequest fehlerfrei angekommen ist, sendet die NMS eine Bestätigung (GET-Response). Falls die NMS den SNMP Inform nicht bestätigt, weiss der SNMP Agent im Router dass er den SNMP Inform noch einmal senden muss. Das ganze läuft ebenfalls über das schlanke und overhead-arme UDP. Soweit so gut aber woher weiss der Router nun eigentlich welcher konkrete InformRequest bestätigt worden ist? Ganz einfach, das NMS bestätigt den Eingang eines SNMP Inform mit einer GET-Response Nachricht mit genau dem gleichen Inhalt an den Router zurück. Damit weiss der Router, dass genau diese Nachricht mit all ihren Inhalten erfolgreich angekommen ist oder nicht. Das NMS plappert also einfach den Inhalt des eingegangenen SNMP Informs in einer GET-Response Nachricht nach – ziemlich einfach und effizient.
Jetzt stellt sich lediglich nur noch die Frage wo ist der oder die Häken? Prinzipiell kann ich nicht sagen, SNMP Informs sind generell besser als SNMP Traps. Ein SNMP Inform hat auf jeden Fall den Vorteil, dass der Router weiss, dass die Nachricht angekommen ist und kann im Fehlerfall erneut versenden. Netzwerkfehler können also wesentlich besser ausgeglichen werden und die Kommunikation wird zuverlässiger. Die Kehrseite der Medaille – ein SNMP Inform benötigt auf einem Router mehr Ressourcen. Schliesslich muss der SNMP Inform im Speicher gehalten werden und bei Bedarf erneut gesendet werden. Der eingehende GET-Response muss verarbeitet werden und verbraucht damit mehr CPU Zeit. Der Kommunikationsaufwand ist höher, da eventuell neue SNMP Informs gesendet werden und pro SNMP Inform zusätzlich ein GET-Response erzeugt wird.
Ich hoffe damit wurde ein wenig Licht in die SNMP-Trap vs. Inform Thematik gestreut. Wem das alles nich gefällt kann ja dann noch Syslog machen aber das steht in einem anderen Blog – Mir isses egal OpenNMS kann Traps, Informs und Syslog ;)
So long ...
 |
Die Firma Didactum Security GmbH war als Aussteller auf der OpenNMS User Conference vertreten. Im Anschluss waren Sie so frei und haben mir eine Teststellung der securityProbe 5E mit ein paar Sensoren zur Verfügung gestellt. Die Integration in OpenNMS ist mit Temperatur, Luftfeuchte und der Verarbeitung von SNMP-Traps in den aktuellen Entwicklungsversionen 1.8 master und 1.10 master out-of-the-box möglich. In der nächsten stabilen OpenNMS Version 1.8.14 sollte dann der einfachen Umgebungsüberwachung nichts mehr im Wege stehen. Die Integration ist im Issue-Tracking von OpenNMS unter NMS-4156 dokumentiert. Wer zufällig eine securityProbe am Start hat und einen oder mehrere der folgenden Sensortypen einsetzt:
|
Da ich gerade dabei bin meine verwendeten Internetdienste aufzuräumen, ist nach dem Fresseheft nun Scribd aus meiner Anwendungsliste geflogen. Ich bin der Meinung, dass man ein simples PDF auch ohne Werbung-gegängele hosten kann.
Viel Spass beim stöbern ...
So Long, and Thanks for All the Fish
if [ "interest" != "open-source-off-topic" ]; then skip_this_entry exit 0 else continue fi
Bei uns kommt es hin und wieder vor, dass wir extrem viel Zeit im "Zum Eck" in Fulda verbringen. Meiner Meinung nach die einzige ehrliche Kneippe - Jepp ohne eigenen Internetauftritt. Ich glaube einer der wenigen Orte wo man Nerds, Geeks und andere normale Menschen offline in der freien Wildbahn antreffen kann ;)
So kommt es dann doch auch recht häufig vor, dass eine allabendliche Diskussion mal so eben bis morgens 7:00 Uhr dauert. In einer nicht unähnlichen Situation und bei viel "Club Mate" hatte ich mir noch einmal Gedanken über mein Google+ Problem und meine Timeline gemacht - Fragt nicht :) Herausgekommen ist eine kleine Kritzelei die sich wie folgt darstellt:
Eigentlich würde ich mir momentan eine Timeline wünschen, die Google+ und Twitter beinhaltet. Noch besser würde ich es finden, wenn ich die Timeline interessengetrieben filtern könnte. Eigentlich sowas wie ein "Fuzzy-Schieberegler" für interessen. Mal so global gesponnen von "Infotainment" bis runter zu "Entertainment". Die Timeline wird von oben nach unten mit mehr "entertainigen" Themen angereichert. Für die Fuzzifizierung habe ich mir verschiedene Themen überlegt. Da ich mir meine Brötchen über diese ganzen Informatik und Computerkram verdiene, werden ganz oben nur die Themen angezeigt, die für mich "überlebensnotwendig" sind. Je weiter nach unten der Regler geschoben wird, desto mehr "Nebenthemen" werden in die Timeline eingeblendet. Also quasi von Job only bis hin zu alles anderen inklusive Rofl und Lol und Not Safe For Work (NSFW) ;) Wenn das alles funktionieren würde, dann könnte ich sogar einen Scheduler einbauen der mir an einem Arbeitstag nur gescheites Zeug anzeigt und abends erst den ganzen anderen Kram. Wenn ich dann an der Arbeit von meiner Timeline abgelenkt werden, dann wenigstens mit etwas, was mir auch noch was bringt :) Wäre ja dann auch eine Möglichkeit Firmenpolicies einzuführen. Man könnte also das Socialnetwork-Zeuch mit der Arbeitswelt vereinbaren, aber das steht wohl auch in einem anderen Blog. Soviel zum Gekritzel ...
Ta Daaaa !!! ... Der Timeline-Fuzzy-O-Mat ...
Im Artikel noemail von Tarus Balog findet man folgenden Satz:
So, I am really digging the Google+ thing, but I am worried that it is going to become the time suck monster that Facebook became ...
Currently in my opinion ... more yes than no.
Nach mehreren Tagen Google+ kann ich bisher als Fazit sagen, dass es bisher das gleiche zeitfressende Monster ist wie der Konkurrent Facebook. Ich hatte mich heute mit meinen Freunden ausgiebig über G+ und deren Konzepten unterhalten – teils mit unterschiedlichen Aufassungen – genau das gehört ja allerdings dazu, sonst wäre es ja langweilig ;) Der Artikel von Kristian Köhntopp - Queryologie zum Thema G+ hat mich da auf jeden Fall zum darüber nachdenken inspiriert – Danke.
Ich möchte in G+ Informationen verbreiten. Ich kann in G+ die Information unterschiedliche Mengen zur Verfügung stellen. Ich verwende bewusst den Begriff der "Menge", es gibt im Prinzip zwei Mengen-Typen.
Die Circles-Menge – die Summe der Personen in Circles – ist eine Teilmenge von "public".
Ich kann eine Information erstellen und mit der Menge "Public" oder einer von mir definierten Teilmenge teilen – "sharen". Ich kann Informationen die ich über eine Person erhalten habe, weiter verteilen – "resharen".
Problem: Wenn ich eine Information über eine Person erhalten habe und an "Public" "reshare", erhält die Person von der ich ursprünglich die Information erhalten habe, die Information noch einmal und diese erscheint in Ihrer Timeline ein zweites mal. Voraussetzung, die beiden Personen haben sich bidirektional als bekannt markiert. Wenn jetzt wiederrum eine Person aus meinem Bekanntenkreis die Information "reshared", mit der ich ebenfalls in einer bidirektionalen Verbindung stehe, erhalte ich die gleiche Information ein drittes mal. Das versaut mir und jedem anderen die Timeline und macht das ganze extrem konfus.
Ich folge auf Twitter Personen sehr gezielt und komme an sehr konzentrierte Informationen. Die Tatsache, dass bei Twitter nur wenige Zeichen erlaubt sind, führt dazu, dass für mich "crowd-sourcing-technisch" Informationen verdichtet und gefiltert werden. Ich muss vieles einfach nicht mehr sehen und lesen. Die Timeline bei G+ ist für diesen Zweck – abgesehen von den redundante Einträgen – viel aufwändiger zu verarbeiten. Eine Twitter Timeline kann ich in extrem kurzer Zeit in meinem Twitter-Client "scannen". Bei G+ ist das viel aufwändiger, momentan brauche ich dreiviertel meines Screens nur für die Anzeige der G+Timeline. Gut ich gehe mal davon aus, dass sich das in naher Zukunft mit besseren Tools lösen lässt.
G+ unterscheidet nur zwischen Personen und nicht deren Interessen. Die Timeline stellt mir entweder die Informationen der Menge aller mir bekannten Personen dar oder einer Teilmenge der mir bekannten Personen. Es gibt keine Hash-Tags um für mich interessante Inhalte von unbekannten Personen in meiner Timeline zu haben. Allein aus diesem Grund kann ich leider noch nicht auf Twitter verzichten. Sparks sollen diese Problemdomäne besetzen, funktionieren für mich allerdings überhaupt nicht – Vielleicht ja auch ein Layer-8 Problem ;)
In Sparks werden zwar Inhalte nach Interessensgebieten angezeigt, wie und woher die jedoch genau kommen, hat sich mir bisher noch nicht erschlossen. Ich teile die Meinung von Kristian Köhntopp, dass Sparks eigentlich viel wichtiger sind als Circles, jedoch kaputt sind.
In einem Punkt vertrete ich eine etwas andere Ansicht wie im Artikel "Queryologie":
Circles sind ein gutes Konzept für einen Sender, mit dem er potentielle Empfänger für seine Nachrichten bestimmen kann. Dabei sollte sich der Sender bei der Wahl des Circles nicht von den Interessen des Empfängers leiten lassen, sondern ausschließlich von seinen Sicherheitsinteressen. "Enthält diese Publikation irgend etwas, das mir schaden könnte, wenn ich es +public mache?".
Wenn die Antwort "Nein" ist, dann kann der Artikel auch mit +public raus - egal, ob meine Follower sich dafür interessieren oder nicht.
Es ist Aufgabe der Empfänger sich ihre Kommunikation zu organisieren.
Die Verbreitung von Informationen hat für mich nicht nur etwas mit der Tatsache zu tun, etwas von mir in die Welt zu blasen – Wer Informationen verbreitet hat auch ein Ziel für die Information. Das kann auch bedeuten: Jeder der in der Lage ist die Information zu konsumieren. Ich möchte die Information nicht in schwarz/weiss - bekannt/unbekannt - sondern Themen spezifisch veröffentlichen.
Ein kleine Beispiel:
Vielleicht möchte ich eine Information an eine Menge aus "public" minus "Menge an bekannten Personen" veröffentlichen. Ich will einen bestimmten Teil meiner Personen mit dieser Information gar nicht "belästigen"? Natürlich kann ich die Information ja nur an einen Circle versenden, das wiederspricht jedoch meinem Exhibitionismus und ich möchte ja von Unbekannten wahrgenommen werden :)
Wenn ich Informationen verbreite wie mein 1,5 jähriger Spross gerade erste Gehversuche macht. Für die Menge "public" sicherlich interessant, die an dem Themengebiet Spass haben. Für alle anders orientierten Personen die den vorherigen Beitrag zur politischen Situation in Syrien gut fanden und nun folgen, vermutlich eher weniger und "verschmutzen" die Timeline.
Über das "Markieren" von Informationen kann "ich" als Ersteller oder Sender dem Empfänger/Abonnenten die Möglichkeit geben, selbst festzulegen ob er eine Information haben will oder nicht. Vielleicht möchte ich von Kristian Köhntopp ja Informationen zu Politik und Technik in meiner Timeline sehen, wenn er allerdings Fotos über kürzlich verzehrte Mahlzeiten postet, dann kann ich darauf eigentlich ganz gut verzichten ;) Sparks sind für mich an dieser Stelle einfach viel zu global und ungenau. Ich weiss aber, dass Herr Köhntopp Sachen schreibt, die für mich relevant sind.
Wenn A etwas über Comics schreibt, dann interessiert mich das, wenn A etwas über Fashion schreibt dann eben nicht – Sparks müssten mit Personen in Circles geschnitten werden.
Bei Twitter ist die Verbindung Thema und Person über Hashtags besser verknüpft. Ich kann einfacher gezielt Informationen einer bestimmten Person über ein bestimmtes Themengebiet erhalten. Es ist nicht optimal aber besser als in G+.
Für mich fällt das weitläufig gesehen, also eher in den Bereich der Netiquette und wiederspricht ein wenig dem Ansatz, dass der Abonnent/Empfänger allein dafür verantwortlich ist, was in seiner Timeline auftaucht und was nicht. Der Ersteller der Information muss halt zumindest markieren. Bei Twitter passiert das manuell – wenn das markieren von Informationen in G+ automatisch geht, dann wäre das super genial ;) Dann könnte ich als Informationskonsument irgendwann wirklich festlegen, was ich konsumieren will und was nicht – mit all seinen Vor- und Nachteilen, dass steht aber in einem anderen Blog :)
Letztendlich habe ich mich auf jeden Fall dabei ertappt, dass ich viel mehr Zeit in G+ verbringe und wesentlich weniger sinnvolle Informationen erhalte, wie es in Twitter der Fall ist. Bei Twitter bin ich nicht jedes mal gezwungen den Inhalt zu sehen, der hinter einer Short-URL liegt. Bei G+ werden in der Timeline alle Informationen komplett angezeigt. Man wird viel leichter verleitet, Zeug zu lesen, was man eigentlich gar nicht lesen will :) Aus meiner Sicht müsste man es irgendwie hin kriegen, dass die Timeline kurz und knapp gelesen werden kann und erst wenn es mich näher interessiert, die volle Anzeige bekomme. Schreiber von Informationen müssten "gezwungen" werden Inhalte kurz und treffend zu beschreiben.
G+ hat für mich auf jeden Fall das Potential Facebook, Twitter und Co. zu ersetzen. Bis dahin isses aber noch ein Stück, ich bin auf jeden Fall gespannt und lasse mich gerne eines besseren belehren ;)
Mittlerweile isses 4:56 Uhr wird Zeit ins Bett zu gehen und ich bitte entsprechende Rechtschreibfehler zu entschuldigen, lies mich einfach nach der schönen und informativen Diskussion mit Tak und Thargor einfach nicht schlafen :)
