IBM Cloud - Structured Ideas

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Post your ideas

Start by posting ideas and requests to enhance a product or service. Take a look at ideas others have posted and vote them if they matter to you.

  1. To post a new idea - select "Add a new idea" and where asked select the appropriate category this idea relates to. Provide requested information to allow us to get a better understanding of your request.

  2. Vote ideas that matter most to you.

  3. Get feedback from the IBM team to refine your idea.

Help IBM prioritize your ideas and requests

The IBM team may need your help to refine the ideas so they may ask for more information or feedback. The offering manager team will then decide if they can begin working on your idea. If they can start during the next development cycle, they will put the idea on the priority list. Each team at IBM works on a different schedule, where some ideas can be implemented right away, others may be placed on a different schedule.

Receive notifications on the decision

Some ideas can be implemented at IBM, while others may not fit within the development plans for the product. In either case, the team will let you know as soon as possible. In some cases, we may be able to find alternatives for ideas which cannot be implemented in a reasonable time.

NOTE: All IBM employees must enter Ideas through this Ideas Portal.

ELK Adapter enhancement to send logs to different ELK endpoints based on Org/Space

We would like for IBM to evaluate enhancing the ELK Adapter implementation to log to multiple ELK endpoints.  We need the flexibility to send logs to the respective ELK instance (non-production applications log to a non-production ELK instance).  We would like to configure the logging destination at the space level.

  • Guest
  • Feb 16 2017
  • Delivered
  • Guest commented
    5 Dec, 2018 02:28pm

    Just released, Log Analysis w logDNA [] supports multiple resource groups to support logging isolation in the account. Up to 32 logDNA instances can be support per account.

  • Guest commented
    1 May, 2017 05:12pm


    We currently support enterprise application logging with ELK and have both production and non-production ELK environments to support that. The two environments are mirror images of each other and located in different data centers so that the non-prod environment can provide disaster recovery for the prod environment. Given ELK is our Bluemix logging solution we need the ability to log to non-prod ELK from our non-prod spaces and to production ELK from our production spaces. This is because logging in non-prod typically occurs at higher levels than prod, and, more importantly, production log data will have different retention requirements than non-prod log data.

    With the ELK adaptor’s inability to log to multiple end points we are forced to drop another infrastructure layer in between Bluemix and ELK to provide the filtering/routing necessary to ensure that log data goes to the right ELK environment. There is obviously more cost involved with the additional infrastructure, not to mention the fact that it introduces another point of failure.

    Ideally the ELK adaptor would be somewhat configurable and, at a minimum, able to route based on space name.

    Please let me know if you have any additional questions.

    Thank you!

    David E. Spotts | Manager, Technology Services | BNSF Railway | 817-352-3838

  • Guest commented
    4 Apr, 2017 08:05pm

    Another consideration is that non-prod environment is used as a load testing environment by teams resulting in abnormally large volumes of logs. So, we cannot drain the non-prod logs to Prod BNSF ELK stack as that can be risk slowing down or worst case bringing down the Production ELK stack.

  • Guest commented
    4 Apr, 2017 08:01pm

    Ananda, We do not have the separation at this time. We have been draining all Bluemix logs (all spaces, dev, non-prod and prod) to our non-prod BNSF ELK stack. However, this is a huge risk as the Production applications in Bluemix do not have the same guarantees of availability and message loss from BNSF ELK stack as other non-Bluemix applications who are using the Production ELK stack. The Production BNSF ELK stack is highly available and the non-prod BNSF ELK stack is not guaranteed to be highly available. Also, we have limitations where security zones (separate security zone for Prod vs non-Prod) do not allow Production application components to connect to non-prod components. Thanks, Runu

  • Guest commented
    4 Apr, 2017 01:31pm

    Hi Ananda, we have different ELK environments (Development, Trial, Production) that corresponds to different spaces in our Bluemix environment.  Therefore, we would like to send logs from each of the Bluemix space to the corresponding ELK environments.  At this time, Bluemix logs from all spaces are being sent to only one ELK destination/environment.  We need help to configure logs from each space to sent to the correct corresponding ELK environment.


    David Nguyen 

  • Guest commented
    4 Apr, 2017 04:44am

    Hello. Thanks for adding this idea to the portal.

    Would you please add some details about why you need the log destinations emanating from a single private Bluemix environment to go to multiple destinations and configured at the space level? How do you achieve this separation today? What difficulty do you run into without this ability?

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.