Debian 9 amd64
Zabbix 4.0.x

I have voted to solve this issue, but I think it's strange it isn't given high priority. In my use-case it makes Zabbix completely useless in many cases. I've been using it for more than 10 years and I have become to rely on the dashboard for many things.

I just realized that this "low priority entry" is in fact about a certificate that's going to expire in 3 days.

The text however implies that it's still 19 days to do this.

All these years this has worked properly and I really don't understand how this change could ever have happened.

Only 36 people have voted for this change and if that's some kind of indication when this gets resolved I'm not feeling optimistic.

This is one of those cases where democracy doesn't work. Zabbix has always been a solution for people that are using it like I do, maybe being a minority. Now it suddenly isn't. The opportunity to "vote for it" is, imho, not the correct way to handle the priority of this bug.

Zabbix is typically a solution that isn't upgraded that often, so there may well be a majority that's completely unaware of the direction development is heading and that majority may not be able to use it either. It's also my mistake to have upgraded so soon, but in all these years this always was to my advantage. Only this time it hasn't.

Can someone give some indication on how long this situation may continue? I am considering to downgrade to <4.0, but that depends heavily on that time.

This was partly solved in 4.0.3, please read https://support.zabbix.com/browse/ZBXNEXT-4792 accordingly.

I'm very happy with the solution in 4.0.3!

@Marco, I'm surprised that you are happy with the 4.0.3-solution. You created this call, after all? (Thank you for that, BTW. )

The new column that was introduced in 4.0.3 is nothing more than a workaround. I'd really have a hard time to explain to my users how to parse the output, so I don't even try updating from my 3.4 installation. When going to 4.0 I would have to rewrite most of the templates and some of the alertscripts to make output usable again, but I really hope that this gets fixed in 4.2...

@Marco

Are you referring to the optional added column that represents the real value?
Why do I need a wrong value in the first place and a correct one in another column?
Zabbix, for me, was all about a dashboard explaining the problem giving only the data one needs to know for solving it.

The added column is hardly something to make me happy, but it is welcome as it relieves a bit of the pain.
It's only working for triggers where the values itself is shown. I am sometimes referring to other macros that may have changed and this column doesn't work then.

I have always tried to create triggers with normal English sentences that pinpoint the exact problem with giving the correct parameters and outcomes. This has been destroyed now.

It is bigger than {ITEM.LASTVALUE}
None of the macros are updated. I even want more live data in the trigger description and that isn't coming either. For years I would like to be able to display the value of the expression instead of only being able to display {ITEM.LASTVALUE}. Now {ITEM.LASTVALUE} is not even displayed correctly. Maybe it should change to {ITEM.FIRSTVALUE} as that's what it is now.

The creator of this ticket has a different use case than I do. The dashboard is displayed as a gimmick for showing of live data on a TV screen. That's totally not what the dashboard is for us. For us, the dashboard is crucial as an early warning system to display problems so we can prevent worse from happening.

Just had a discussion, sad news is, this is very unlikely to be coming in 4.2 . Keep voting and let's hope for 4.4.

I can't even begin to understand how someone would make a change like this.

It's like someone said "We have improved the performance and can now give you an answer much quicker than before, the only problem is that the information is outdated...."

I'm also not hearing anyone about that it's not only {ITEM.LASTVALUE}, but any live data you may want display in the Trigger description. The only reason why I update Zabbix is the apparently false hope that we can get MORE live data in the trigger description. Like going to the hairdresser to get a nice haircut and leaving with your head shaven .

I only care about live data, so I probably will export all the templates and hosts and import those on a new Zabbix 3.x installation.

I support colleagues and I don’t understand how it was possible to remove support for displaying live data (LASTVALUEx) in the board Problems.

The Last Values column on the Problem board is simply useless and inconvenient.

Our company will not be able to upgrade to version 4 due to this problem. I think many companies will not upgrade to version 4 because of this feature.

Agree! It's difficult to explain the reason of this solution....

We use livedata functionality of {ITEM.LASTVALUE} pretty heavy in our Zabbix installation. I think around 80% of all templates have at least one {ITEM.LASTVALUE}, mostly in trigger name. The "Problem" view with latest values is essential in the way we use zabbix everyday, and even with "show latest value" column, we have to rewrite all our templates to get rid of {ITEM.LASTVALUE}, and replace the trigger description to something more generic.

But the problem still presists in other places, alerting with escalations for example. When long-standing problem escalated to the manager, guess what values and trigger name it contains?

Also very shocked at this change. I have a trigger that something drops below 500, and couldn't understand why it it was stuck at 0 for long. Turns out the lastvalue isn't the last value at all! 

The formula that I use for the trigger is complicated, and having the column of latest values showing would just give our users a stream of numbers with no meaning! We need this functionality back. 

I'm also waiting for upgrading our production servers and proxies to 4+. Upgrading from 3.4 to 4.x should give us more, not less. I'll issue this in our support contract.

I'm curious why this has been labelled as "New Feature Request". It's functionality we want back that was removed. 

we also use this macros for 90% of trigger names and wait for fix this function before upgrading

I also use this functionality and find it very irritating to have it removed. Please bring it back!

This issue has also been linked in https://zabbix.org/wiki/Features_removed .

We rely heavily on our Zabbix dashboard in our environment, which is a large an complex one, with more than 1k VPS and thousands of devices on our largest Zabbix.  Our triggers have been configured with {ITEM.LASTVALUE} to make the alerts and their current status easily readable so that our NOC can better triage the problems as they come in.  I upgraded one of our smaller environments from 3 to 4, and was dismayed to find that {ITEM.LASTVALUE} no longer functioned as expected.  While I appreciate the addition of the Latest Values column, it lacks the readability of having the value in the trigger itself.  Our workflow depends on this, so it is preventing us from upgrading our main environment from 3 to 4, which we have been keen to do to take advantage of all the new features in 4.  I would gladly trade some measure of performance to be able to have a clear, understandable, and up-to-date dashboard.  Please return the functionality of {ITEM.LASTVALUE}.

I've just found this. I'm struggling to understand how this is a feature request. Surely it's a bug fix as functionality that was there is no longer working, if it was discussed at summit 18 was the use cases of it not considered? The workaround doesn't really address the issue either.

Whilst I appreciate this is probably DB load related, surely it should be an option (maybe by use of a different macro) to either have the triggered value or the real actual last value.

I think it makes sense, if you have problem you don't care what was the value that caused it, it is much more informative to know what is the current value causing it.

I would like to apologize for the regression. Now it is absolutely clear to me that we highly underestimated impact caused by removal of this functionality, it appeared to be very popular and has great practical value. Your comments speak volumes! I appreciate it very much.

We cannot provide a good fix it in 4.0.x due to changes of the database structure, we don't do it in minor releases for obvious reasons. Therefore we should aim for 4.2.x, I think it is doable. Most likely it will be implemented as an optional trigger attribute, say, 'Problem note', which will contain text having various macros and will be displayed in the problem view.

I hope it helps.

Thank you very much Alexey for the answer. Zabbix is the best open monitoring system and we want everyone to be comfortable with it.

>>Most likely it will be implemented as an optional trigger attribute, say, 'Problem note', which will contain text having various 

It seems to me that a separate column for displaying LASTVALUEx will not be convenient.
Look at the image below with the triggers from our monitoring system, as it is convenient to see the values at which the problem occurred and the current values.

>> It seems to me that a separate column for displaying LASTVALUEx will not be convenient.

I agree that it may not be the best solution, we have to consider various options. I like your proposal in general, however I think that we should separate problem name and the additional information somehow. It can be one string yet with visually different parts.

Previously, people decided how and what would be separated themselves. Did it at their discretion. I consider that it is necessary to return everything as it was, and the user will figure out in what format to display a message for himself.

>>  I consider that it is necessary to return everything as it was...

It is not possible. Problem and event names must be static, therefore {ITEM.LASTVALUE} cannot be used there. Otherwise:

1. We cannot search by problem/event names
2. When sending event details to 3rd party systems {ITEM.LASTVALUE} will remain unexpanded

How should I read last comment?

Personally I'm totally not interested in the 2 features that would suffer.
The dynamic nature of the trigger value is imperative and I would even like to see it expanded so it can be more dynamic.

Does this mean that we are not getting macros (with its real current value) back into the trigger description?

What I want and what was always possible is that I could create a trigger description with a human-readable sentence that would tell me the nature of the problem with values that are relevant to the problem.

I'm currently waiting for this feature to come back. If it doesn't I would like to downgrade Zabbix and consider it end-of-life for my purposes.....

I don't know why no answer is coming.

I merely like to know if I can continue with Zabbix. I can be patient and wait several months for this feature to come back. I can continue to struggle until that time.

But eventually I want to have it like it always was. If that's not possible that would be sad for me and I think many others. I will then be forced to downgrade to version 3.0.25 and continue to use that for the remaining time.

If it's at this moment already sure that the feature will not return (I'm getting mixed messages) then I would like to know now.

I can prepare to create a 3.0.25 environment and try to get my current hosts / templates  in.
I hope it turns out to be not that difficult.

@Alexei Vladishev

Maybe you are not answering my questions because you misunderstand my intentions.

Currently I'm running 4.0.4 RC2 and I can cope for the time being. If it would be easy to downgrade Zabbix to the latest 3.x version I would do it immediately. I'm only continuing to use 4.0.4 because I may be able to run some 4.x in the near future which I can configure so I can use it like I always used it.  With current, live data in the problem description on my dashboard.

I'm now starting to think that a future release in 2 months time will still not be what I can use.
The only thing I'm asking is to please confirm / deny this.

I would prefer not to wait several months and then find out that this problem that's created will never be solved.
In that case I can better start to examine how I can downgrade to a 3.x version.

As I understand the problem is in internal redesign of handling events/problems, to have "Monitoring -> Problems" which is based on new database table "problems". With this new design it's not possible to offer the same level of dynamic data in problem view. In order to just "go back and make it as it was" we'd have to go back to the old design and this is probably what alexei meant when saying "it is not possible". This is just for you to understand why we can't "just bring it back".

As to your concern about 3.x, I completely understand that and that there is no sense in wasting time, if feature is not coming back. As I know it is currently planned to fix it somewhere in 4.x but there's no straight and clear vision as to how and how easy it would be. Probably internally (as suggested by vjaceslavs) we'd have to introduce another level between "Trigger name" and "Event" (e. g. "Problem name") that'd allow having what is asked here. But that needs to be designed, evaluated, approved and only then we can give some estimates. I hope you can wait some more before starting to plan downgrade.

Guys, I hope that the issue will be resolved in one of 4.2.x.

If it won't be resolved in 4.2.0, it won't be resolved in 4.2.x for the same reason it wasn't resolved in 4.0.x - "no database changes allowed".

Gleb, we've already made all necessary DB related changes to make it possible in 4.2.x.

Great news! Apparently these changes sneaked under my radar.

@dlimir thanks for explaining and am planning to wait to see how it will unfold.

Was anything rolled in to 4.2? I don't see any changes in the What's New or the manual page for triggers.

No, not regarding this issue.

I just noticed that even if you change the static description of a trigger it's not even reflected as long as the issue is pending.
How can that ever be a good thing?

You are right, this is current behavior. And for me this is also inconvenient, but potentially there could be someone that would like to see "how it was" at the time of event. As vjaceslavs suggested (during our internal discussion) the only solution to satisfy everybody here is to make this configurable.

People work different, but I can't imagine a situation in which it would be convenient to keep a static description after updating a template.

However, I can see how it could be useful to keep the item's value in the trigger description "how it was". That's why there is the distinction between {ITEM.VALUE} and {ITEM.LASTVALUE}. So I don't see how it would be necessary to make this configurable...?

Don't get me wrong: almost anything is better when it's configurable. But in this case, I'm desperately waiting for the problem view to be useful again. I'd rather see this feature reimplemented as quick as possible. There are several features in 4.0 and especially in 4.2 that I really want to use. I just can't update as long as the problem view shows outdated values.

There are some edge cases when keeping the old problem name can be helpful. For example, when reviewing alert history and seeing how a particular trigger started firing more or less frequently, it can be useful to right away see that the trigger was changed (assuming the change was also reflected in the name, not only in the expression).
That is likely a less common usecase, and would be more beneficial as an option in the event (or problem history) view.

Just voted for this issue - for us it is the same as for others like Ronald, the static texts in the dashboard just make 4.0 unusable and prevent us from upgrading to it - we would really appreciate when this is going to be fixed in 4.2 and be able to upgrade to 4.2

The problem is worse, imagine this trigger

Your disk is {11GB} free, it will be full in {3 days}

If 11GB and 3 Days stay static, then forecasting becomes useless.

Not only such static name trigger would go mostly ignored, it would also not show updates if any temporal mitigation action is taken, ie: stopping some processes and deleting some log files but no space addition:

Your disk is {18GB} free, it will be full in {7 days}

What I still do not get is, if it can be done in a new column, then it is only a display/format issue, just adjust the html page... It could probably be done with a Greasemonkey script

What I don't get is why it ever was considered in the first place.
Years ago I wanted a dynamic macro which I could show in the trigger name that would show the outcome of the expressions used in the triggers.

I never even got any reply even though it would help my use case a lot. Now I can do even much less than I did then.

I also would like to be able to use macros in the trigger url which is also not possible

Pfffff... it's not 12.5 hours old.... It's several days old

@Alexei Vladishev

Hi

is there any progress in solving the problem? In which release 4.2.x can we expect the return of {ITEM.LASTVALUEx} functionality?

Thanks

Can we get help for the database to downgrade to 3.x???

Sorry, we do not support downgrades. We recommend having backups before performing the upgrade. Hopefully you have one.

Just a quick update. We still hope to address it in the earliest 4.2.x, working on design currently.

I just reread everything we have here. I realized that nearly everyone would be happy if we returned the original functionality back. But I strongly believe it is going to be a very wrong decision, here is why (once again):

1. It is impossible to search by dynamically evaluated problem or event names
2. When sending event details to 3rd party systems {ITEM.LASTVALUE} will remain unexpanded

I am sure it is not a popular opinion here, but I cannot imagine that a generated problem may have a name that changes over time! It is wrong.

Zabbix 4.x has the following logic:

Problem happened ->  it gets name assigned -> the name is static, so it can be exported, sent to other systems, etc etc. Great!

Now the question is how to get {ITEM.LASTVALUE} back.

We have introduced additional column displaying current values in 4.0.3. It appeared to be insufficient for many of us, I think mostly because we cannot have a nice human readable sentences like "Number of transactions per second exceeded 1000, we have 1240 currently".

Our current idea is to introduce an additional free-text field when you could basically create a helper text with any macros you want including {ITEM.LASTVALUE}. The text will appear somewhere in the list of problems (the design is to be finalized), so the problem above might be displayed like:

"Number of transactions exceeded 1000"
^{Threshold: 1000 Cur: 1240 Avg min: 945 CPU load: 2.54 <- small helper text below, nice!}

Reading comments above I understand that some of you are not happy about such approach, am I right? Please give me good reasons why. Force of habit perhaps?

Please tell me what you think.

I think the solution Alexei just described would work great as long as we would be able to use that free-text field with expanded macros in actions (and thus in media integrations).

Alexei, would you consider a filter option or switch to completely replace the Problem name with the dynamic helper text? In that case the old style templates would work again. Still keep the static entries in the Problems table, have them searchable etc. 

While at it, the current values column is ok, but may become useless when displaying text fields and combining multiple items. ZBXNEXT-3316 would solve this greatly. 

It sounds like a good solution to me - having a free text field which allows us to give some context to the value (especially in triggers with multiple items this should be important) brings back what we actually need. Still don't like the necessary reworking of our trigger templates, but obviously this can not be avoided as the original behaviour will not come back.

Most likely, an idea with an additional free-text field is the only best solution.

But I would like to:
1. In this additional free-text field it was possible to use all available macros that can be used in the trigger name + ITEM.LASTVALUE worked in zabbix 3.x.

2. So that in the web interface for this field you can change the font size (via include/defines.inc.php) and this field is located strictly under the name of the trigger (alarm). Ideally, it would be cool if the format of the Problem field could be also set via include/defines.inc.php, for example, by the type of output printf:
Format:
%s\r\n%s
Output:
Number of transactions exceeded 1000
Threshold: 1000 Cur: 1240 Avg min: 945 CPU load: 2.54

Format:
%s (%s)
Output:
Number of transactions exceeded 1000 (Threshold: 1000 Cur: 1240 Avg min: 945 CPU load: 2.54)

I like the idea. Also, it would be nice to have an option to to toggle that field and choose where it is displayed, eg: Under problem name, Column after problem (kinda like what Mikhail suggested but from the frontend)

Additional columns, sub-rows etc (even customized by some kind of user-defined template) do not improve instant dashboard readability & end user experience. Technically it's just an improvement of the unsatisfactory workaround introduced in 4.0.x.

P.S. I remember Alexei saying that Zabbix company should start eating its own dog food (ie start using Zabbix, not just developing it). Maybe the time has not come yet, and I hope it won't be too late when it comes.

Many thanks for all the feedback and nice ideas! I hope to come up with high level design doc in a few days, will keep you updated.

Great ideas here. Please note that problem (previously - trigger/event) names also appear elsewhere, including Monitoring -> Maps, Monitoring -> [IT] Services, screen (dashboard) elements etc.

If this is critical for somebody, they might want to summarise the desired functionality in zabbix.org not unlike the specifications, for example, https://zabbix.org/wiki/Docs/specs/ZBXNEXT-282 . Notice the "Also discussed" section - it would be crucial to document solutions that were not deemed satisfactory, along with the reasons why so.

A proposition from ingus.vilnis seems like a good idea.
Just to add a comment about this because this feature was unique for Zabbix - no other NMS system that I work with had that option.

I like Zabbix logic for hostname where you have a real hostname that must be unique and ZBX uses that for internal mechanisms, but at the same time you have VISIBLE name option where you can put anything you like and that would appear everywhere in GUI.

Maybe you can implement an option where you can define "visible trigger name" on trigger configuration that will appear everywhere in Zabbix GUI, and at the same time keep the original event for searching purposes. Of course, this option is valid only if there is no big performance impact on viewing and analyzing events...

Like ingus.vilnis and aldin.osmanagic said, I like the idea to consider an option to completely replace the Problem name (static event name) on the dashboard with your 'dynamic helper text' or better "VISIBLE Trigger Name" fully, so the users see the same UI design and behaviour as before

I feel like adding subrows and other columns takes space and downgrade user experience, and is a fix on top of a fix (the additional values column, barely readable)... I don't like it personally.

Thank you for following your users and I really hope a fix would come soon, which doesn't change the design but restores the old functionnality, while keeping static events for the obvious reasons you said before.

Alex Vladishev explained why it would be a bad idea a bad decision and comes with the reasons that it will make it impossible to search and that 3rd party software would have a problem with it.
I don't know why Alex is of an opinion that those feature need to be necessary. I have no 3rd party software nor do I have any reason to search for problems that are no problems anymore. There are enough problems in the world to see problems without searching for it.

I'm using Zabbix as a real-time status dashboard that tells me what is going on now!
If I need triggers that tell me that a problem occurred in the past I will create a special trigger for it.

I would like to go back to 3.x if this doesn't happen.
@dimir said I should have made back-ups before upgrading, but it took a long time before I noticed I wasn't getting proper feedback from Zabbix anymore.
By the time I noticed what was wrong with it, those back-ups were recycled and also obsolete as many hosts were added by that time.

Why these extra features (static data of initial problem event) that are apparently needed by some weren't just added to Zabbix is beyond me.
After I noticed it I wanted to go back to 3.x, but I didn't because I was under the impression that it would be fixed in the near future.
If I knew then that it would not be fixed in July, I would have.

The question now remains... Should I downgrade or not?
If I know now it will not be fixed in another 3 months time I prefer to downgrade so I can at least have current data instead of old data which is of no value to me.
It's not that I'm asking for an ETA to put pressure on it at all. I just need some coarse info so I can make a decision.
At this moment I'm getting mixed info and it seems that those who are making the decisions don't really want it.
I am afraid that I need to to go back to 3.x in October anyway and that I have struggled an extra 3 months for nothing.

I think we all agree that the main use case is to see operational data in order to understand where we are (estimate impact and future trend, if possible).

I would suggest to introduce a new trigger attribute called "Operational data". Therefore we will use operational data for any data we want to be additionally displayed in the list of problems, for more static data we use trigger name and description. That's how it may work:

1. A new trigger attribute "Operational data" will be supported, empty by default
2. It will support all macros currently supported by trigger name and also {ITEM.LASTVALUE<N>}
3. A new macro {EVENT.OPDATA} will be supported in all contexts currently supported by {EVENT.NAME}
4. Filter in both Monitoring→Problems and dashboard widget "Problems" will be extended to support a new option "Display operational data":
   1. None: no operational data is displayed (default)
   2. Underline: non-empty operational data will be displayed under problem name with smaller font size
   3. In problem name: non-empty operational data will be displayed in brackets after problem name like "<Problem name> (<operational data>)". For example: No free disk space on / (thold: 20GB, cur: 12GB)

You may ask, why it is not called visible name? Visible name will basically require duplicating of trigger name + use of macro {ITEM.LASTVALUE} in configuration of triggers, no good. Also it will be confusing in search results. It is named as "Operational data" in order to give users a hint that this should be used to display some real-time information about given problem.

Does it sound like a reasonable fix? Opinions?

Sounds great! This will solve the problem with live viewing for me.
One moment: will this data be visible from the API?

An intriguing solution, thank you Alexei.

What about other frontend sections like network maps?

> What about other frontend sections like network maps?

I don't want to over-engineer it, perhaps we should just display it as "Problem name (operational data)" by default without any additional options.

> One moment: will this data be visible from the API?

Yes, in a new field problem.opdata. I think it should be supported only for problem.get, but not for event.get.

So in the end this results in the following: In older versions, we had one dynamic field for the trigger/event name, which will now split up into a static and a dynamic part and will be shown together as one? This sounds the closest we can get to the old behaviour everybody here seems to like, so it is a good solution (under the assumption that we accept the first change as good anyway - I can not really support that, but that might obviously be different for people with other use cases)

I like the idea of Alexei, when can we expect its implementation?

>I like the idea of Alexei, when can we expect its implementation?

I will wait a few days for any useful feedback then it goes straight to development.

>we had one dynamic field for the trigger/event name, which will now split up into a static and a dynamic part and will be shown together as one

Trigger name is also a dynamic field, i.e. it will accept all currently supported macros. The only difference is that the new field will handle {ITEM.LASTVALUE} nicely.

IT sounds great. For 4.4?

Will this be back ported to 4LTS? Or at least to 4.2?
A way for those with productive systems who can neither downgrade (impossible) nor upgrade to a dev version (inappropriate)

So a trigger defined with {ITEM.LASTVALUE} will be able to show operational data in the dashboard just by changing a propety in the Problems widget correct?  There is no need to change anything in the trigger itself correct?

@Matias No, I think that with the new method from Alexei you will need to change all your old triggers to add the operational data in the new trigger attribute "Operational data" (in the trigger configuration).

Then you would need to enable the new option "Display operational data" in the Problems widget on the dashboard once, like you said.

I think this workaround is a good idea, even if we need to change all the triggers of our templates (which is a bad thing). But if someone has a better solution, that would be nice!

Do I understand correctly that we then have 2 lines per problem @ problems view?

Or will I be able to display only "operational data" on the problems view?

Do I need to edit all our triggers to make this functional?

Tbh as far as I understand the idea I don't like it. I'd rather prefer the current workaround with the latest value column...

Currently we support additional column "Latest values" in the problem view. I think that instead of displaying operational data underline or in problem name, we can do better:

1. Rename column "Latest values" to "Operational data"
2. Rename filter option "Show latest values" to "Show operational data"

Therefore if the option is enabled Zabbix will display operational data (using format defined for trigger) in the column or (if it is empty for a trigger) list of latest values and links to corresponding graphs on mouse over.

After looking at design prototypes I believe that displaying extra information in a separate column is the best choice.

What do you think? It is supposed to be implemented in earliest 4.2.x.

@alexei so what you're saying is that we won't ever get the dynamic text back in the actual Problem field? i.e. the only solution you're proposing is a new field with operational data in it. 

This is still a major problem - I have triggers that use multiple conditions (interface description, speed, status, etc) and I don't want the precious space on the screen taken up with all of that text when it's just one value that I want to display in text. The whole point of the Problem text is that it's meaningful

@alexei, I think that this design is quite OK and some additional options would allow us to revert to the original display style if preferred by the user.

1. Add an option to use the trigger name template to render the operational data in a dashboard or problem view.
2. Allow to not show the trigger name in the dashboard or problem view.

Another (probably even simpler) possibility would be to make an option that allows the user to choose whether to render the view with the static event data or "live rendered trigger templates".

What really bothers me about most of the proposed solutions until now is that they will require us to go through all trigger configurations to fix/change them. This is not a small thing for a lot of users and, in my opinion, it should be taken into account more when designing changes.

Craig, it will be up to you to define what kind of information you want to display there. Only if the operational data field is empty, Zabbix will display most recent values in the column like it is implemented with the 'Latest values' column now.

Bart, trigger configuration needs to be adjusted only to remove {ITEM.LASTVALUE<N>} macros or move these macros to the new field. All other functionality will continue to work absolutely fine.

I agree with @bart.kroon, it would be better to keep all the existing triggers without changing their configuration, if it's possible.

@alexei, is it possible to "just" add the option to render macros to their latest data in the widget ? If it's not then I think it would be better to add an option to see the "operational data" field right after the problem name, in brackets, rather than a separate column.

Just a quick status update. I've decided to keep it simple, i.e. it will be implemented as an additional column without ability to include this information into problem name in brackets. If column view will not be sufficient and we get many complains then it will be extended one way or another.

Another important thing to mention is that it will be done for 4.4.0 only, no backport to 4.2.x which I planned initially. The reason is very simple, we are just a few months away from Zabbix 4.4, it makes little sense to backport it since the official support of Zabbix 4.2.x will be over in October or November this year.

Now it is under development, the functionality will be available soon in first alpha releases of Zabbix 4.4.0.

Wouldn't the simplest solution be to add a checkbox "Live data" that is enabled by default? How much chances are there that people would want some of the macros resolved one time and see live values of others?

Alexei, what about the approach you mentioned for maps?

dimir, all - it feels like the suggested new column will be just like the trigger name previously. I suspect that most users will want to get rid of the problem name column and just show the new column, thus re-implementing the previous functionality (albeit at a cost of potentially reconfiguring all triggers, unless DB upgrade puts trigger name in "operational data" everywhere).
With that in mind, showing both problem name and operational data columns will likely be a waste of space - for most users. Customising columns (ZBXNEXT-850) is unlikely to appear any time soon to be a solution for that.

Summarising the concerns: if the new "operational data" will be just like the old trigger name, why not provide a global switch between them?

People with smaller installations can happily get back the behaviour they loved. People with large installations get performance gains at the expense of the current data, although for them a checkbox like dimir suggested might be useful (or it could be a feature creep - those people apparently have not complained about the breaking changes).

@richlv,

>Summarising the concerns: if the new "operational data" will be just like the old trigger name, why not provide a global switch between them?

Technically yes, it can be used as a replacement for trigger name. But it serves a very different purpose, i.e. it is all about providing additional data that helps to understand current system state. I do not want to introduce confusion by introducing any switches, otherwise the new field should have been called "Visible name", I already explained why it is a bad idea.

So as I understand it {ITEM.LASTVALUE<1-9>} is indefinitely kaput and will only be the same thing as {ITEM.VALUE<1-9>} and instead we will have to change every effected trigger to put the information into a new field call "operational data". Is there no hope for ever getting {ITEM.LASTVALUE<1-9>} back working?

In the past there have been other very important ZBXNEXT requests, where the specifications have been made public available through a PDF whitepaper. Will Zabbix publish such a PDF for this request here, too?

Marco, thanks to the reminder! We will do it soon.

Thank you Alexei. You posted your intention here several times in the comments, and people commented back and made suggestions. I think it's very important to make the (final) specification public available for community review in an offical way like a whitepaper, and not just through comments (no offense). That way we can make this process much more open and transparent.

And to be honest, the reason I ask is because I have no idea what the maybe final design is like. I've read about operational data, extra column, no extra column. I just don't know what the current state is.

Please find attached ZBXNEXT-4942 Acceptance Criteria v1.1.pdf - starko

1. Summary should mention 4.0 instead of 4.4.
2. It would make sense to deprecate {ITEM.LASTVALUE} in all contexts where it is not distinguishable from {ITEM.VALUE} to avoid confusion. This include database patch and documentation update.

Do I understand point 3. correct, that the new Trigger attribute "Operational data" will work exactly like the attribute "Trigger Name" did in pre 4.0 versions? It's a free text field that would expand all Macros including {ITEM.LASTVALUE<N>} with latest values instead of the value of the time of the event generation?

If that is true, then we would see two columns, at the same time: The "Problem" column which shows the name of the generated Event, which is the Trigger name with all expended macro values of the time, the event being generated.
And a second column called "Operational Data" which acts like Zabbix 3.4 which shows whatever text we type in that filed, with all macros expended with the difference of macros which provide live values which might get refreshed.

If I did get this right, this sound bit redundant to me, isn't it? I mean, if I would just copy the Trigger Name like I used it in the past into the operational data field, I would see stuff twice, once the event and once the live data. (I know this is a pointless example, but just to make my point clear)

Marco, good point - I had similar thoughts in the comment above.

I agree with Marco and Richlv on this. Adding a column that does what the event name used to do is completely redundant. On top of that it does force us to go trough all triggers and change the configuration to have the opdata field be sensible.

If the frontend is capable of rendering a template with current data, why not add an option to render the dashboard (and any other relevant view) with current data. That would allow anybody that wants the static view to have that and anybody that likes to have up to date values can have those visible. It would save another database change, fitting another wide column in the dashboard (how will this ever fit on a regular HD screen) and probably quite a bit of coding.

Keeping with the static representation of events in the database is fine, an improvement still, since now the trigger history finally has sensible values!

I totally agree with Bart Kroon, Marco and richlv and  on this. It's a little redundant, and it would make the dashboard difficult to display on a big screen.

Either please add an option to show the columns the user wants (Only op. data, only static problem name or both), or even better :
An option to render live data instead of the "problem name" (show "op data" OR static data), like Bart said, and make the "Op. data" column optional.

I don't know why it would not be possible if it's already possible in a separate column. Thanks.

Isn't it exactly what I proposed above?

Wouldn't the simplest solution be to add a checkbox "Live data" that is enabled by default? How much chances are there that people would want some of the macros resolved one time and see live values of others?

@Dimir, yes it is!

I agree with Bart Kroon, Marco, richlv, Jim, and dimir.

@dimir Oh, I missed your comment.. Didn't know you were part of ZABBIX team. I agree with that great option!

Yes @dimir, that sounds like a good idea, but isn't mentioned in the PDF in any form, hence my feedback regarding the PDF, as this is the current official plan.

My opinion here is just like yours, I'm not involved in the process of development of this feature.

I also agree that this sounds like a better solution, to me and probably most users, that just want the old functionality back.

But, given that the main reason for this change in the first place was about the requirement to have static trigger names, how would it work? Would it be a checkbox in every page that displays triggers? Or a global config? And if so, how would we search for the "static" trigger names? And how would this "parsed/visible trigger names" be passed to the 3rd parties?

I honestly just would like to have the old functionality back. I'm just trying to point out the issues raised by Alexei about possible confusion, because it kinda feels like we are in a loop here.

It could be a global config for everywhere except in search ? Or in the dashboard, with the new operational data "replacing" (with checkbox option) the problem name?

I thought I would post this here since it is related to showing dynamic information (Macros) in the trigger name or somewhere close to it in the dashboards.

Look at this example where I use spikes, a calculated item (free space delta [max-min] of the last two weeks):

Trigger name: Low disk free space 14GB for 25GB spikes. Now: 12GB (7%) [3d 8h 5m] on disk C:\

The only static value is 14 {ITEM.VALUE1} , the rest are {ITEM.LASTVALUEX}. This gives the operator an idea of what exactly triggered it, what is the current situation, and what should be done (in this case enlarge the disk by at least 11GB (25-14)

Math is supported in the trigger evaluation but not in the trigger Name. The most we have there is the regex functions to alter ITEM macros, but that is for text. I would like to show the 11GB (that would go in a different ticket/request) without the need of creating another calculated item putting more needles load to the DB. Maybe a new {ITEM.EVALUATIONX}

I mention this here since it might be relevant for the way this ticket will be solved.

Resolved in development branch feature/ZBXNEXT-4942-4.3

Changes in API documentation:

• Event object
• event.get
• Problem object
• problem.get
• Trigger object
• trigger.get
• Trigger prototype object
• triggerprototype.get
• Changes from 4.2 to 4.4

Changes in user documentation:

• What's new in Zabbix 4.4.0
• New trigger
• Configuring a trigger
• Triggers
• Dashboard widgets
• Problems
• Supported macros
• Low-level discovery macros
• User macros supported by location
• Using macros in messages

If I understand the screenshot from the implemented solution properly, I do not think this helps at all!

Imagine a trigger with a descriptive problem including 2 items and 2 lasttiems, and a trigger logic with 10 items which come in mixed order

The Title Code

Your disk had only <ITEM.VALUE5> and it needed in <ITEM.VALUE7> minutes to be full. Now it has only <ITEM.LASTVALUE5> free and it will be full in  <ITEM.LASTVALUE7> minutes

The Original Title Expanded

Your disk had only 200 MB and it needed in 30 minutes to be full. Now has only 100 MB free and it will be full in 5m

The New Title in V4

Your disk had only 200 MB and it needed in 30 minutes to be full.  
Operatonal data: item1.value 0, tem1.lastvalue 1, item2.value 1 GB, tem2.lastvalue 1 GB, item3.value 4m, tem3.lastvalue 4m, item4.value 500 MB, tem4.lastvalue -700 MB , item5.value 200 MB, tem5.lastvalue 100 MB, item6.value 6, tem6.lastvalue 0, item7.value 30m, item7.lastvalue 5m, item8.value 3m4d34m, item8.lastvalue 3m4d38m, item9.value 10 MB, tem9.lastvalue -10 MB, item10.value 100 GB, tem10.lastvalue 100 GB, 

The Zabbix operators will kill me and then kill theselves if they get this solution.

Or is there still a chance that I understood the screenshot wrongly?

AS, you can use the same syntax you are using for trigger name. So feel free to format operational data as you want. So in your example, trigger name could be:
"Your disk had only <ITEM.VALUE5> and it needed in <ITEM.VALUE7> minutes to be full."

And operational data would be:
"Now it has only <ITEM.LASTVALUE5> free and it will be full in <ITEM.LASTVALUE7> minutes"

In that case it is a neat solution. I can have a short static Problem description, and a dynamic detailed explanation.

Implemented in 4.4.0alpha3 (master) 98a2ff6, c9f3a45

1. I found a bug when displaying data in the web interface, see the screenshot.

my screen

To reproduce the bug, the "Operational data" field in the trigger prototype should be empty, and the "trigger name" field should be of the form "Free disk space on volume '{#FSNAME}' (free: {ITEM.LASTVALUE1}, total: {ITEM. LASTVALUE2}, threshold: {$ FREE_SPACE_CRIT: "{# FSNAME}"}, alert started: {ITEM.VALUE1}) ".

Then the trigger worked and an alarm appeared. Then I fixed the template and rescheduled "(free: {ITEM.LASTVALUE1}, total: {ITEM.LASTVALUE2}, threshold: {$ FREE_SPACE_CRIT:" {# FSNAME} "}, alert started: {ITEM.VALUE1}) in field "Operational data", but on the board there were no changes in the Problem column.

2. Displaying the "Operational data" field by a separate column is very inconvenient, it takes up extra space on the screen. It is more correct to display "Operational data" in the line "Problems", but in a smaller font.

That is not a bug, problem names are static. You get the same thing now in 4.2, if you update a trigger name for a trigger that is active, it will not change, only new problems after the change will be affected.

Thanks João Andrade, ok, let this not be a bug.

How about improving the user experience design and wrapping the "Operational data" column as a row  (in column "Problem")  with a smaller font ?

alexei what do you think of this?

Examples image 1 (column "Problem" and "Opdata" together on the 2 line (no column separation))

or

Examples image 2 (column "Problem" and "Opdata" together on the same line (no column separation))

Checkbox "Show operational data" will continue to work and disable the display of operational data in the "Problem" line

When is the new functionality going to be available for test? The repo only goes to the alpha version:

ii  zabbix-server-mysql                  1:4.4.0~alpha2-1+buster       amd64        Zabbix network monitoring solution - server (MySQL)

The two lines suggestion (Title/Subtitle) is a great idea, width real estate is already tight.
And there is somehing similar already today, the "Show details" checkbox.
We could add the  "Show Operational Data" checkbox and have a sane UI experience.

Last but not least @alexei

it will be done for 4.4.0 only, no backport to 4.2.x which I planned initially. The reason is very simple, we are just a few months away
from Zabbix 4.4, it makes little sense to backport it since the official support of Zabbix 4.2.x will be over in October or November.

 It makes full sense, But what about 4.0?

Craig, you can grab the fresh code from git until the next version is released - perhaps https://zabbix.org/wiki/Get_Zabbix#Using_official_git_client helps.

Mikhail, A. S. - there have been a few suggestions to add a toggle between problem/operational data. While Alexei has mentioned his objections to that, I have to admit not fully understanding the reasoning.

Rather than toggling between the two, I would show the extra data or not.(on/off)
Most cases where it is defined, it will definitelly need both.

My patch for showing "operational data" as single line:
https://gist.github.com/CHERTS/4fa1fa47c8caab68e52c4de2216d4c84

P.S. In the CSV format, the opdata field is still exported as a separate field.

richlv, I run my install from apt. When are the changes due in the repo?

Craig, that would be up to Zabbix, whenever they release and package the next version.

Build on Ubuntu 18.04 LTS (Bionic Beaver) with MySQL (MariaDB) support:

1. Prepare OS:

cd ~
sudo apt-get update
sudo apt-get install -y autoconf automake gcc make wget unzip libxml2-dev libssl-dev libcurl4-openssl-dev libsnmp-dev libevent-dev libsqlite3-dev libpcre2-dev libssh2-1-dev libmariadbclient-dev-compat
wget https://github.com/sass/dart-sass/releases/download/1.22.10/dart-sass-1.22.10-linux-x64.tar.gz
tar -zxf dart-sass-1.22.10-linux-x64.tar.gz
export PATH="~/dart-sass:$PATH"

2. Build from latest git source:

cd ~
wget https://github.com/zabbix/zabbix/archive/master.zip
unzip master.zip
cd zabbix-master
./bootstrap.sh
./configure --with-libpcre --with-libcurl --with-libxml2 --with-net-snmp --with-openssl --enable-ipv6 --with-ssh2 --enable-server --enable-proxy --enable-agent --sysconfdir=/etc/zabbix --with-mysql
wget https://gist.githubusercontent.com/CHERTS/4fa1fa47c8caab68e52c4de2216d4c84/raw/b7acd75337e8256003675211980f34a2c304aba9/zbx_440alfa3_opdata_one_line.patch
patch -p0 < zbx_440alfa3_opdata_one_line.patch
sed -i 's/sass --no-cache --sourcemap=none/sass/g' Makefile
make

3. Check zabbix_server binary:

ldd src/zabbix_server/zabbix_server

4. Create mysql schema file:

make dbschema

5. Make php frontend localezation and css

make gettext
make css

6. Create new mysql database, user and import mysql schema file (schema.sql, images.sql, data.sql)

7. Run src/zabbix_server/zabbix_server with new config file

8. Install new web-frontend (frontends/php) to your web server and connect new database.

9. Testing new features

One improvement proposal to the above mentioned instructions:

4. Create database files:

make dbschema

Thanks @dimir

I don't understand most of what is written here. I don't get why Zabbix default behaviour ever had to change.
If for other use cases another behaviour is wanted then in most software you need to use a new procedure.
With Zabbix 4.0 the default behaviour was just changed and became useless for many including me.

Anyhow... I want to look forward as it seems some code has been introduced so we can get live data shown again like we did a year ago.
For that sole reason I upgraded to an alpha version.
My Zabbix is now running 4.4.0alpha3

Yet... I still not see live data in the trigger name.
I believe I'm still not understanding how I can get live triggers back

Can someone help me please with this?

I'm getting this when the latest back-up is 23 hours old.

What do I need to do to have it show 23 hours instead of that value of 6h and 7 mins ??????

My trigger is:

SQL backup Chex is older than $1 ({ITEM.LASTVALUE1})

Dear frater, you need to go to trigger configuration and copy-paste some part of trigger Name into Operational data (in your case that would be "({ITEM.LASTVALUE1})"). Then back in Monitoring → Problems you (and your users, I guess) need to check Show operational data option in the Filter.

I need to use another example as that other trigger is not active anymore.
I'm still not able to get it working, so I'm probably not doing it correctly.

I now getting this data.
A misbehaving DHCP-server (one that never releases a lease) is monitored.
If the amount of leases get close to 250 this will be a problem, so I created a trigger that will start at 150 leases.
I want to give the info that there are 181 leases now.
It is showing 151, because that was the first value when it crossed (obviously).
(Still not understanding how that will ever be informational....)

This is the trigger sentence that needs to be displayed: More than $1 lame clients ({ITEM.LASTVALUE1} leases

The checkbox "show operational data" only gives me an extra box with the value 181 which I don't want there, but in my sentence.
I don't want that column at all.

So how do I get {ITEM.LASTVALUE1} in the trigger description???

"More than $1 lame clients" in name field.

"{ITEM.LASTVALUE1} leases" in opdata.

IMHO the change should have been a checkbox "show static values instead of dynamic" for each trigger.

You can't. The behavior of the trigger name was changed and it now will always display the data that was there when trigger fired. Now if you want current data associated with it, only thing you have is that column.

@Frater: You find a description of the change here: https://www.zabbix.com/documentation/4.4/manual/introduction/whatsnew440#operational_data_of_problems

You find the new config here: https://www.zabbix.com/documentation/4.4/manual/config/triggers/trigger#configuration

The "Trigger Name" has been changed in 4.0 and will never be the same again. Zabbix wanted to achieve, that the Trigger name always represents the status from the moment the Event was generated. Hence the name will never change again. No more live data in trigger name. To reflect the feedback from the community, which used the Event Name as a live view in <4.0, the column "Operational data" was added in 4.4.
If you copy the Trigger Name into to "Operational data" column, it will behave exactly like <4.0 You then you would see the data that triggered the Event and the live data at the same time.

I'm also not happy with the solution, but it's what we get and it's much closer to 3.4 than the "latest data" column in 4.0.x.

So how do I get {ITEM.LASTVALUE1} in the trigger description???

You can't

Is this really what we are getting after waiting all this time???

what a crap solution to a problem that was written into the software.

Who actually wants to read yesterday's news????

@Frater
You want the old behaviour of the Trigger name (Problem) back what we won't get anymore.

Instead we now have an extra column "operational data" which can be modified for each trigger. This column will always show/evaluate latest data instead of taking the initial value like in the Trigger name.

I also don't like this solution, it is like the added "Latest value" column which now can me modified. And you have to do this for every trigger!

For example the Trigger name is "Free disk space problem" and the operational data "Current used data: {ITEM.LASTVALUEx) from {Item for total space}". Before the trigger name was like the operational data and it worked.

As I said now you need to modify every trigger with operational data...

I only hear about the people that "don't want this solution".

But how many people really want the current solution? 5 people, 10 people?
Am I belonging to a minority or to a majority?
Has anyone even investigated this?

If I really belong to a minority than I should just downgrade to Zabbix 3.4

@Frater We draw a line between event name (static) and operational data (real-time). Why don't you use operational data? What stops you? I understand that it requires some effort to update existing triggers and perhaps notification messages, I do not see any other issues.

Can't we have a vote how many people want the static trigger description?
There is now a "reverse vote" which is imho totally unrepresentative.
I think most Zabbix users are still using 3.4 and are even unaware of this change.

Yet this minority decision has been pushed through.
I suspect it comes from a few commercial users with huge databases that are struggling with speed.

Can't we have a front-end patch?
The live data is there and I just want it concatenated to the orignal sentence instead of a seperate field.
I can then choose to only fill the field "operational data" and leave the trigger description blank.

@Frater if you want to merged the columns "Problem" and "Operational data", then you can use my patch for zabbix frontend -> https://gist.github.com/CHERTS/4fa1fa47c8caab68e52c4de2216d4c84

Beside that I don't like how it is pushed and I don't love to change all the triggers, I of course want to take an effort of making it work for me.

What about my previous proposal?
Concatenate the operational data with the trigger description and show it in one field.
I can then write most of the stuff I want in "operational data"

@Mikhael Grigorev
I will investigate that.

@Alexei
Can't we get that as standard behaviour (I haven't seen it yet, though)???

@Frater Perhaps it is an unpopular decision in this thread but there will be no return to the old behaviour. Event names cannot be dynamic! Once event is generated it should have a static definition. Otherwise we will not be able to transfer events generated by Zabbix to 3rd party systems, for example.

For 3rd parties there could be a separate column representing trigger metadata which is always static.

@Alexei Vladishev

I recognize that "resistance is futile"
But an additional fix where (optionally) the trigger description gets merged with the operational data upon display will make both camps happy.

The ones that only need static trigger descriptions can leave the field operational data empty and do not check any box that will merge operational data.

The only thing that needs to change is the meaning of the checkbox "show operational data"

@dimir no more separate columns, please

@dimir
I want to go forward.. It has now sunk in that we are the ones that need to adapt to the new situation. I see a possibility there.
What we are given now in 4.4alpha3 is not adequate, but with a little change I think it will be.

@Alexei Do you agree that merging the 2 fields upon display does not influence "your side" in any way negatively??

@Mikhael Grigorev
I tried to patch your patch with the CLI "patch", but it rejected it.

Is it indeed a patch for the 4,4alpha3 version of that file or should I use it in a different way.
I used:

patch frontends/php/include/classes/screens/CScreenProblem.php zbx_440alfa3_opdata_one_line.patch

I have to agree with @frater in one point, the visibility in the Frontend. I fully understand the change to the Eventname being static since 4.0 @alexei and there is no way to change that. I understand the addition to the trigger configuration with the filed operation data, where I can add text and macros like I could in 3.4.

I don't understand that I don't have the choice to display it in frontend 4.4 like I could in 3.4. Wouldn't this this solve all problems at all? You have the static event that are needed for 3rd party and certain business cases, but still provide the 3.4 live view without affecting any database related changes? We are already 90% there, you made the development changes to allow operational data, only the display of both columns is maybe a bit complicated. Also more problems in "Problems" view isn't good on small screens. Swapping Static Event Columns with operational data event columns optionally by a switch the user can decide for, sounds like a good way to saturate all needs?

My understanding is that the change had purely technical motivation - to improve performance by avoiding name/value evaluation many times (especially in big environments).
This technical motivation seeped into user experience because the usefulness of the existing functionality was not fully understood.
There's some internal resistance in Zabbix to "give users what they want" - an ability to choose between realtime and static values all over the frontend[1].

It feels like there's an attachment to the original change, a desire to see it as a good one despite user feedback.
Is that to any extent how the Zabbix team feels like?

[1] It might be a mistake to go through this same discussion for maps and every other affected page.

The current implementation of Zabbix now has an extra field where "operational data" can be filled in.
I have no problem changing all these triggers. It will take me day's work, but I think that's worth it.

The only thing that still needs to be done is a change in the frontend behaviour.
Instead of showing 2 separate columns on the customizable dashboard, it should show both of them merged together in the problem description in color.
Effectively I can get the original behaviour back by only starting the sentence in the problem field and finishing it of in the second field.

As I see it there is then only 1 little question to be asked. "Should we let Zabbix fill in the extra space between the 2 sentences or should we do that ourselves by starting with a space in the operational data field?"

It should do this only when the checkbox "show operational data" is checked.
The dashboard now reacts by creating a separate column. I don't think anyone wants that.

I wish I was able to apply Mikhael's patch. It may just well be exactly what I want.
I will now cycle to work and there I will try to patch it manually.

As I see it "both camps" would have their way and we all win.
I have invested more than 10 years in Zabbix and I would hate to be stuck at version 3.4 forever.

Please do recognize that how Zabbix 4.4 behaves now is not how we can properly use it.
I'm only "hanging in there" in the hope that we finally get live data shown in a proper way.
I think we are very very close and Mikhael's patch may just well be all we need.
I can't judge that yet.

"Given the users what they want" is a bit ironic...
In fact we were giving something we didn't want in 4.0

But let's be constructive about it. We're almost there as I see it.

@richlv The motivation was both technical (you are correct about performance and such) but more importantly it was about having good architecture. Main point here (repeated many times here) is that event name (once generated) must be static, period. Having said this I don't mind at all to discuss and invent some better ways of how information we have in Zabbix should be presented in the UI.

@Frater We actually did usability testing when information is merged like "<Event name> (<op data>)". It does not work and look well, unfortunately. The problem is that trigger names quite often already contains brackets with some useful data and thus we end up having information displayed like "CPU load is too high (over 1.5) (now 1.72)". When you have many problem the information become unreadable (kind of stair-like view since event names have different length) that's why we put operational data into a separate column.

@Frater @Marco I don't know, if we get enough votes we could probably implement merging of two columns like I described above (optional & controlled by filter), use it at your own risk.

I haven't tried the 4.4-solution, yet. But my understanding is, that the column with operational values works exactly like the old behavior of the trigger name. Am I getting this right?

If so, it shouldn't be too big of a problem to make the problem view configurable. So a user could have a 'static' text in the trigger description, a 'dynamic' text in the operational data field, and a possibility to choose what should be displayed in the front end: static column, dynamic column or both. I guess that would be better (and cleaner) than simply merging the two columns.

I don't remember for sure, but I think somebody proposed something like this already, somewhere above.

I don't get the problems that could arise when concatenating the 2 sentences and show them in the dashboard?

I would also be fine if the static sentence is not shown at all and I can have the operational data shown in colour.
I'm totally not interested in any display of the information at the moment it was triggered.
Now it's not coloured and given as obscure additional info when it is in fact the most important info of the whole trigger.

The mere presence of the display is already giving away that the trigger is valid.
To know by "how much" it overstepped the threshold the moment it was triggered is most of the times hardly informational.
In the case of my leases it's always the threshold +1 in case the interval is quick.

Again.... I'm only proposing a change to the dashboard and I'm happy if my preferred view is not the default anymore....
I don't think it's reasonable to also expect us to be happy with patching the software each time and not being able to get it properly supported.

> @Frater @Marco I don't know, if we get enough votes we could probably implement merging of two columns like I described above (optional & controlled by filter), use it at your own risk.

How many voted for this static view

@ros Yes, Operational Data works exactly like 3.4

+1 What ros says, it's exactly my opinion.
As said before, I fully understand the change by Zabbix, and it makes sense. Now that we have Operational Data, we only have to "fix" the visibility in the Dashboard (or more important for me personally) -> the Problems View.

The patch provided by @Mikhail Grigorev appears to be for a different version.
When I download the source of alpha 3 I'm getting a frontends/php/include/classes/screens/CScreenProblem.php with a time-stamp of Sep 19 15:44

The patch Mikhael created is for a Sep 7th version.

Did anyone see it working?
I would love to know if it works exactly like I want to.

There are a 100 votes for those wanting to keep a live view.
Maybe Mikhael's code already does what we want, so it only needs to be merged.....

@Frater

See instruction above: https://support.zabbix.com/browse/ZBXNEXT-4942?focusedCommentId=364254&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-364254

@Mikhail Grigorev

Yes, that's exactly with we (are at least I) want

Now I can start to change all my triggers.

Will this patch be implemented in the main branch?

Wouldn't that give me the confusing sentence: "More than 150 clients (151) More than 150 clients (181)"  ??

+1 vote for ability to merge problem and operational data in the dashboard view

@Vjaceslavs Bogdanovs The operational data isn't shown in the severity color

Anyone else tried Mikhael's patch?
For the time being it works for me.

Ticket can be closed after that patch is merged

Oh... The ticket is already closed

I have been working with Mikhael's patch to 4.4 alpha 3 for a few days now and I am satisfied with how it is working.
I do needed to update all the triggers so the dynamic part is in the second field, but I'm at least not getting a seperate column.

All is well again

However............................

None of the devs are reacting anymore and it seems (I'm saying seems) that the patch Mikhael has created will not become mainstream.

@Alexei Vladishev  I have a feeling you do not want to add the patch @Mikhael Grigorev created to the frontend. I so hope I'm mistaken. Can you please let us know what we can expect? 

Alexei, thank you for clarifying.
I'm sure nobody opposes the benefits and the need for static event/problem names.
The only thing most people on this thread seem to be confused about - why not give the users a choice of what is displayed?

As for voting, that's 45 votes on ZBXNEXT-4792 and 100 here.
This is the 15th most voted-for issue - but this was created in 2019, while most of the ones with more votes are around since 2009.

In vain, but bringBackSpecsZabbix++

I agree with @Frater. I liked the solution proposed by @Mikhael Grigorev better. I am using the patch available and it fits in well with the proposal to view the "latest value" in a more elegant way than the separate column.

This is non optimal...

I also agree with @Frater !

+1 vote for the patch, the ability to merge problem and operational data columns in the UI (optionally), AND have the live data colored as it was before.

The team did a great job implementing op. data, even if the user will have to change every existing trigger.

The UI (dashboard + problems view) should be more configurable to match user needs if possible

I hope we can manage to include proposed solution into 4.4.0rc1 if everything goes well, stay tuned.

@Alexei

That's great!

The most important part is that the patch will be included and become part of mainstream. When, is of less importance, but I would of course welcome it if it is already included in 4.4.0rc1.

And of course many thanks to Mikhael for creating the patch and therefore showing its feasibility.

@Frater It will not be implemented exactly as proposed, an option to display it as a separate column will also be supported.

OK..., to make sure....

It will be possible for us to set it in a way that it creates 1 natural sentence into 1 coloured column without any separate column???

In other words...   we can set it in a way that it behaves like Mikhael's patch?

Noticing a just-created ZBXNEXT-5482, not sure what's going on.
This must be one massive misunderstanding. I just cannot understand how it happens to be.
Perhaps nobody has been able to describe clearly enough what is the useful way for that feature to operate.

@richlv

I think they also want to preserve the view that was introduced by the team. So 3 choices instead of 2.
I don't mind. As long as it is possible to get a view where these 2 fields are merged into 1 column.

Let's see it before judging.

Given that Mikhael's patch has shown what most of us want, we should be able to trust the devs to make the correct changes.

I am already content that I don't have to revert to Zabbix 3.4 and eventually have to stop using Zabbix because there is no support for it. Maybe now there's also room for more dynamic data.

It was implemented under ZBXNEXT-5482 and included into 4.4.0rc1, feel free to try!

@Alexei 

It works fine... 

RC1 however introduced a new anomaly in the "By Severity" view.
This has nothing to do with the "live view".

It may be helpful for you to know that it was still OK in alpha3.

frater, please try to clear browser cache. Ctrl+Shift+R or Command+Shift+R (for Mac users) can help.

That worked...
Sorry...

I'm so glad I finally have "Zabbix back" 

Please, my comments in ZBXNEXT-5482 regarding brackets