Running the OBIEE 12c startup on Windows: C:\app\oracle\fmw\user_projects\domains\bi\bitools\bin\start.cmd Just hangs at: Starting AdminServer ... No CPU being consumed, very odd. But then … looking at DOMAIN_HOME\servers\AdminServer\logs\AdminServer.out shows the last log entry was: Enter username to boot WebLogic server: And that’s bad news, cos that’s an interactive prompt, but not echo’d to the console output of the startup command, and there’s no way to interact with it. The start.cmd was being called by adding it to the Startup folder (C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp), and I guess it was something about this that stopped the prompt coming back to the console, because when I ran it manually from the command prompt, I got this:

Another quick note on OBIEE 12c, this time on the importServiceInstance command. If you run it with a BAR file that doesn’t exist, it’ll fail (obviously), but the error at the end of the stack trace is slightly confusing: oracle.bi.bar.exceptions.UnSupportedBarException: The Bar file provided as input is not supported in this BI Platfrom release. Scrolling back up the stack trace does show the error message: SEVERE: Failed in reading bar file.

Interesting quirk in running Baseline Validation Tool for OBIEE here. If you invoke obibvt from the bin folder, it errors with Parameter ‘directory’ is not a directory PS C:\OracleBI-BVT> cd bin PS C:\OracleBI-BVT\bin> .\obibvt -config C:\OracleBI-BVT\bin\bvt-config.xml -deployment current INFO: Result folder: Results\current Throwable: Parameter 'directory' is not a directory Thread[main,5,main] SEVERE: Unhandled Exception SEVERE: java.lang.IllegalArgumentException: Parameter 'directory' is not a directory at org.apache.commons.io.FileUtils.validateListFilesParameters(FileUtils.java:545) at org.apache.commons.io.FileUtils.listFiles(FileUtils.java:521) at org.apache.commons.io.FileUtils.listFiles(FileUtils.java:691) at com.oracle.biee.bvt.UpgradeTool.loadPlugins(UpgradeTool.java:537) at com.

Yesterday I wrote about Monitoring Logstash Ingest Rates with InfluxDB and Grafana, in which InfluxDB provided the data store for the ingest rate data, and Grafana the frontend. Mark Walkom reminded me on twitter that the next release of Logstash will add more functionality in this area - and that it’ll integrate back into the Elastic stack: @rmoff nice, LS 5.0 will have APIs exposing metrics too. they’ll be integrated back into Marvel/Monitoring!

In this article I’m going to show you how to easily monitor the rate at which Logstash is ingesting data, as well as in future articles the rate at which Elasticsearch is indexing it. It’s a nice little touch to add to any project involving Logstash, and it’s easy to do. Logstash is powerful tool for data ingest, processing, and distribution. It originated as simply the pipe to slurp at log files and put them into Elasticsearch, but has evolved into a whole bunch more.

Here’s a collection of useful articles that I’ve found over the years that give good advice on writing a good abstract, mistakes to avoid, etc: Adam Machanic - Capturing Attention: Writing Great Session Descriptions Gwen Shapira - Concrete Advice for Abstract Writers Kellyn Pot’Vin-Gorman - Abstracts, Reviews and Conferences, Oh My! Russ Unger - Conference Proposals that Don’t Suck Martin Widlake - Tips on Submitting an Abstract to Conference Bridget Kromhout - give actionable takeaways (post photo courtesy of Calum MacAulay on https://unsplash.

Kibana is a tool from Elastic that makes analysis of data held in Elasticsearch really easy and very powerful. Because Elasticsearch has very loose schema that can evolve on demand it makes it very quick to get up and running with some cool visualisations and analysis on any set of data. I demonstrated this in a blog post last year, taking a CSV file and loading it into Elasticsearch via Logstash.

Two vulns for OBIEE in the latest critical patch update (CPU): http://www.oracle.com/technetwork/security-advisory/cpuapr2016v3-2985753.html?elq_mid=45463&sh=91225181314122121267715271910&cmid=WWMK10067711MPP001C140 Patches is bundle patch .160419: 12.2.1: https://support.oracle.com/epmos/faces/ui/patch/PatchDetail.jspx?parent=DOCUMENT&sourceId=2102148.1&patchId=22734181 11.1.1.9: https://support.oracle.com/epmos/faces/ui/patch/PatchDetail.jspx?parent=DOCUMENT&sourceId=2102148.1&patchId=22393988 11.1.1.7: https://support.oracle.com/epmos/faces/ui/patch/PatchDetail.jspx?parent=DOCUMENT&sourceId=2102148.1&patchId=22225110 Note that April 2016 is the last regular patchset for 11.1.1.7, ref: https://support.oracle.com/epmos/faces/DocumentDisplay?id=2102148.1#mozTocId410847. If you’re still on it, or earlier, time to upgrade! (Photo credit: https://unsplash.com/@jenlittlebirdie)

Recently added to the oracledi project over at java.net is an adaptor enabling Oracle GoldenGate (OGG) to send data to Elasticsearch. This adds a powerful alternative to [micro-]batch extract via JDBC from Oracle to Elasticsearch, which I wrote about recently over at the Elastic blog. Elasticsearch is a ‘document store’ widely used for both search and analytics. It’s something I’ve written a lot about (here and here for archives), as well as spoken about - preaching the good word, as it were, since the Elastic stack as a whole is very very good at what it does and a pleasure to work with.

I’ve recently been playing around with the ELK stack (now officially known as the Elastic stack) collecting data from an IRC channel with Elastic’s Logstash, storing it in Elasticsearch and analysing it with Kibana. But, this isn’t an “ELK” post - this is a Kafka post! ELK is just some example data manipulation tooling that helps demonstrate the principles. As I wrote about last year, Apache Kafka provides a handy way to build flexible “pipelines”.