When you use Skype with Ubutun 11.10 on Unity you will encounter problems when closing it: Usually it just went to the GNOME panel, but now it just disappears. Choosing it from the Unity launcher will complain that there is already an instance of Skype running and you won’t be able to open it again.
The good news: There is a setting that defines which applications are allowed to hook into the panel and Skype is just missing. Run this command to get the current whitelist
lennart ~$ gsettings get com.canonical.Unity.Panel systray-whitelist
['JavaEmbeddedFrame', 'Wine', 'scp-dbus-service', 'Update-notifier']
Now just add Skype to it:
lennart ~$ gsettings set com.canonical.Unity.Panel systray-whitelist "['JavaEmbeddedFrame', 'Wine', 'scp-dbus-service', 'Update-notifier', 'Skype']"
That’s it! Now just log out and in again, start Skype and use it just like you were used to.
I am in the last steps of a Graylog2 v0.9.6 beta release these days: There are only a few tickets for the server and web interface left.
I’d like to take some time and give you an overview about what is changing and coming in this next version of Graylog2.
ElasticSearch is the new message storage
MongoDB has been dropped as message storage. It will stay for message counts (see faster graphs), settings and health values but no longer for storing the actual messages. Reason for this are performance problems when storing a lot of messages. To get a good speed it would have to keep all the messages in memory. ElasticSearch offers fast reads and real full text search features. Future versions of Graylog2 will make use of the full text search features of ElasticSearch - In 0.9.6 you will only get a huge performance increase. MongoDB is still great for storing the other stuff, but using it for the log messages seems to have been a mistake.
Faster graphs
In prior Graylog2 releases the graphs (like the analytics graph and the small stream graphs) were generated (and cached) from actual counts against the message collection. This was getting really slow if you had a high message throughput. From 0.9.6 on the server will count and store the message counts for per minute in MongoDB. This is not only much faster and less IO intensive but also more user friendly: Because it is independent from the message storage you can draw graphs over time periods that are no longer in ElasticSearch. You will be able to only keep messages of the last 2 months, but draw graphs over years. The UI for this will also change to allow easy drawing of long term graphs.
The Analytics Shell
Note that this screencast shows an early version of the shell. Count, distinct, and distribution queries for example are now displayed in the shell itself, not below it. You can also use stream names instead of their IDs for stream selectors.
A lot of bugfixes and improvements. There were some bugs in previous versions that could have been avoided. - Sorry about that. To avoid that in the future there will be a beta release and extended testing phase before releases. Expect improvements in the UX like the one for empty streams: When you created a stream it had no rules and was matching all messages coming in. From now on streams with no rules catch no messages. Streams are also disabled until you enable them - For example after fully configuring the stream rules and alarms.
All in all you can expect a double-awesome version 0.9.6 of Graylog2 that focuses on performance for huge amounts of log messages and long term archiving.
There will be a beta version very soon! A preview version with working ElasticSearch integration is already available for download.
The next version of Graylog2 (0.9.6) will no longer include hostgroups. Let me explain why: You can now build hostgroups using streams since there is a hostname regex matcher rule. The difference is that you are more flexible because of all the other stream filters available. Keeping the hostgroups alive would basically mean having a duplicated feature with less flexibility.
Suggestions or feedback on the mailing list or in the comments of this post.
I am currently working on this new Graylog2 feature. (Screenshot shows the very early stage and is pretty ugly) You will be able to define rules on a time axis that trigger an event. You can define actions (like executing a script, sending an email, …) for whenever an event or a number of events are triggered. Also expect some fancy graphs going far into the history which are perfect for
This will require some Java and Rails hacking in the next time and I am not sure yet if this will make it into the 0.9.6 release or not. Let me know about your thoughts, ideas and suggestions!
I am also very interested in what kind of events you would like to set up.
What a great tour! Only 50km, but really fast and on slippy roads - Perfect to learn keeping your bike under control! Top Speed: 61,2 km/h - Shhooooossssssh!
I spent my last evenings hacking on a new Graylog2 feature which will be very useful for running powerful analytics on your log messages: The Graylog2 Analytics Shell. The detailled description is in the wiki.
Use this shell to extract information from your log messages. I always like the use case of API monitoring. You could easily find out if that one call is still used by consumers - Or even which consumers are still using it with a simple distinct call:
I wrote a little Sinatra application that can be very helpful at optimizing your MongoDB applications. It was very handy while optimizing the Graylog2 MongoDB parts so I made it public and configurable.
It allows you to enable/disable the MongoDB profiler and see it’s results in an overview page. Just start the profiler, run the MongoDB parts of you application you want to test and reload the mongo_analyzer overview page. It will list all queries that took longer than 100ms when in slow queries mode or all queries that were executed when in all queries mode.
You can also view and manage the indexes of your collections to try out effects on the query execution times.
I consider this software as beta. Please report bugs or feature requests in the GitHub issue tracker.
