There are multitude of servers, services, dataflows, metrics, logs and actions - the usual way of perciving the IT field, with monitoring being just "the toolset X", "metrics", "triggers/actions", and logging is basically the same thing. Why can't programs communicate with other programs by saying "Hello! We are alive and have a balanced configuration" or "Please help me, i need another CPU 'cos my workload was changed during last week"? Why are we currently perceiving monitoring from a human point of view? The answer is simple: currently we use "human controls for machines" pattern in a very inefficient form. In this talk Eugene Istomin will speak about true powerful of IT - TOGAF model, code-driven infrastructures, and cover event-driven service discovery. Zabbix Conference 2015

1. 1

2. Pre
My timing starting from 20:00 11.09
20:00 – 24:00 – awesome party
24:00 – 02:00 – awesome Riga
peoples

3. Pre
My timing starting from 20:00 11.09
20:00 – 24:00 – awesome party
24:00 – 02:00 – awesome Riga
peoples
07:21 – first critical SMS from zabbix
...a than ­ help ops & devs
Thanks to Zabbix team! =)

4. What I would tell you if I had had only technical knowledge:

5. What I would tell you if I had had only technical knowledge:
Event­driven
Service discovery1

6. or
What I would tell you if I had had only technical knowledge:
Event­driven
Service discovery
e.istomin@edss.eeEugene Istomin
IT Architect Cone Center,Tallinn
“receive, parse and store
multitude of servers/services/data­flows,
metrics, logs and actions in order to have an
MesosConsuletcd­like service register & discovery”
1

7. Or may be from the business point of view:

8. Or may be from the business point of view:
Business continuity
and the value delivery
2

9. or
Or may be from the business point of view:
Business continuity
and the value delivery
e.istomin@edss.eeEugene Istomin
IT Architect Cone Center,Tallinn
“what is the real cost of
resilience, recovery and contingency”
“risk management on steroids for 6­sigma value delivery”
2

10. The knowledge artifact I have now is about the logitoring lifecycle:

11. Architecture­driven
logitoring lifecycle
The knowledge artifact I have now is about the logitoring lifecycle:

12. or
the meaning of “logitoring” in architecture­driven logitoring lifecycle
Architecture­driven
logitoring lifecycle
e.istomin@edss.eeEugene Istomin
IT Architect Cone Center,Tallinn
“please, no more another
ugly DevOps logging and monitoring pattern”
The knowledge artifact I have now is about the logitoring lifecycle:

13. Logging & monitoring
or logitoring
Do the data in monitoring have
“Time­machine to the
Zabbix Conference 2014”
the same nature as data in logging?
Background to

14. 14
What is the classical
monitoring metric?
Numeric! (int/bool/etc)
IT Monitoring ­ sum of methods used to collect
defined metrics using checks.
Monitoring ~ protocol/agent, desired
data descr, centralized storage,
notifications
= Reactive
Logitoring (Z­conf 2014)

15. 15
Monitoring is usually used for:
● Servers status dashboard creation
● IT­administrators notification
● Numeric info visualization
● IT­inventory
Monitoring In brief:
● Schema­based
● Use common network protocols
or agents
● Stored data not reusable
● Needs by IT eng./admins
Logitoring (Z­conf 2014)

16. 16
What is the classical
logs metric?
String!
IT Logging ­ sum of methods used to
collect pass­through flows information.
Logs ~ syslog, pid/severity/
program, transport, centralized
storage.
= Proactive
Logitoring (Z­conf 2014)

17. 17
Logging is usually used for:
● Problem resolving
● Debugging & development
Logging In brief:
● Schema­less
● Use syslog or API/REST
● Stored data are reusable
● Needs by developers
● Security access violation
events storage
Logitoring (Z­conf 2014)

18. 18
Do the data in monitoring have the same
nature as data in logging?
Yes,
● Monitoring and logging are subsets of
events
● Monitoring is mainly reactive
● Logging is mainly proactive
Events is a set includes
all possible types of messages
(monitoring, logging, JSON data exchange by
HTTP or TCP, etc)
Logitoring (Z­conf 2014)

19. Background to
enterprise architecture
and systems engineering
What is the #enterprise architecture ?
“Complexity is not an objective factor but a
subjective one.”

20. What is the #enterprise architecture ?
A well­defined practice for conducting
enterprise
● analysis
● design
● planning
● implementation

21. What is the #enterprise architecture ?
A well­defined practice for conducting
enterprise
for the successful
development and execution of strategy.
● analysis
● design
● planning
● implementation
using a holistic
approach at all times

22. enterprise architecture
“If we want to solve problems effectively...we
must keep in mind not only many features
but also the influences among them”
and systems engineering
What is the #systems engineering ?
Background to

23. What is the #systems engineering ?
systems engineering is
not engineering

24. What is the #systems engineering ?
systems engineering is
not engineering
What?

25. What is the #systems engineering ?
SE is a technique of using knowledge
from various branches
of engineering and science

26. What is the #systems engineering ?
SE is a technique of using knowledge
from various branches
of engineering and science
to introduce
technological innovations into the
planning and development stages of a system.

27. Business Process of TOGAF

28. Business Process of TOGAF
...process is not that simple as appears in the TOGAF
diagram even with flattened iterations.

29. enterprise architecture
“TOGAF provides a best practice framework for adding value,
and enables the organization to build workable and economic
solutions which address their business issues and needs.”
and systems engineering
Background to
What is the #maturity model for
enterprise architecture ?

30. 5 levels and :
Administration – Governance Roles & Responsibilities
Planning – EA program road map and implementation plan
Framework ­ ..
Blueprint ­ ..
Communication ­ ..
Compliance ­ ..
Integration ­ ..
Involvement ­ ..
Planning – EA program road map and implementation plan
What is the #maturity model for
enterprise architecture ?

31. 5 levels and :
Administration – Governance Roles & Responsibilities
Planning – EA program road map and implementation plan
Framework ­ ..
Blueprint ­ ..
Communication ­ ..
Compliance ­ ..
Integration ­ ..
Involvement ­ ..
EA level 0
What is the #maturity model for
enterprise architecture ?

32. 5 levels and :
No rules at all =)
EA level 0
Administration – Governance Roles & Responsibilities
Planning – EA program road map and implementation plan
Framework ­ ..
Blueprint ­ ..
Communication ­ ..
Compliance ­ ..
Integration ­ ..
Involvement ­ ..
What is the #maturity model for
enterprise architecture ?

33. 5 levels and :
… Captured metrics are used to identify inefficiencies in
EA processes and templates prior to notification of issues
EA level 5
Administration – Governance Roles & Responsibilities
Planning – EA program road map and implementation plan
Framework ­ ..
Blueprint ­ ..
Communication ­ ..
Compliance ­ ..
Integration ­ ..
Involvement ­ ..
What is the #maturity model for
enterprise architecture ?

34. What we have in real IT?
Just a some template without a common sense.

35. enterprise architecture
Layers:
• Business & Information
• Application & Data
• Technical Infrastructure
and systems engineering
Let's talk about #Archimate modelling
Background to

36. open and independent modelling language
Let's talk about #Archimate modelling
Archimate
for enterprise architecture
instruments to enable enterprise architects to describe, analyze
and visualize the relationships among business domains
ArchiMate provides

37. 37
Let's talk about Archimate modeling
From SSH/Zabbix on the right side
to application functions on the left side
Real Archimate scheme

38. “The matter of logitoring
Logitoring
Architecture­driven
logitoring lifecycle
is events/facts provision
to all infrastructure levels.
There are no “logging” or “monitoring” terms anymore ­
Both are just the functions of the event provision engine”
What is wrong with monitoring & logging now?

39. 39
Problems in Communication Between Popular IT Frameworks
https://troikka.wordpress.com/
Colour represent the way thinks:
Green – CIO Gray ­ Enterprise Architects
Blue – PMO Orange – IT service production
“I been introduced to multiple
different IT frameworks ...
but they all failed to capture the whole picture.”

40. 40
Hardware resources & networks
HW abstraction (virtualization, domU OS)
System runtime
(coreos, Containers)
Application servers
App services
(dev code)
Resources
Flows
What's wrong: “rich” vs “clear”
7
Events
getting
“richer”
from
Dev
POV
Events
getting
“clear”
from
Ops
POV

41. What is wrong with monitoring & logging now?
The game )

42. The game )
We need a three persons:
1) Technical one
2) Action­man
3) An Architect
What is wrong with monitoring & logging now?

43. Beep – beep – beeeep... moving to the future
The game )
We need a three persons:
1) Technical one
2) Action­man
3) An Architect
Time mashine moving us to 2025

44. Please describe a successful
The game )
We need a three persons:
1) Technical one
2) Action­man
3) An Architect
In 2025
monitoring­like solutuion1)
The questions from 2025

45. How we will use monitoring­like
The game )
We need a three persons:
1) Technical one
2) Action­man
3) An Architect
In 2025
solutions in 2025?2)
The questions from 2025

46. Describe a value of monitoring­like
The game )
We need a three persons:
1) Technical one
2) Action­man
3) An Architect
In 2025
solutions for end users/IT/business3)
The questions from 2025

47. What is wrong with monitoring & logging now?
The game )

48. “The matter of logitoring
What is #architecture­driven
Logitoring
Architecture­driven
logitoring lifecycle
is events/facts provision
to all infrastructure levels.
There are no “logging” or “monitoring” terms anymore ­
Both are just the functions of the event provision engine”
logitoring lifecycle?

49. “The matter of logitoring
Logitoring
Architecture­driven
logitoring lifecycle
is events/facts provision
to all infrastructure levels.
There are no “logging” or “monitoring” terms anymore ­
Both are just the functions of the event provision engine”
Best practices:
(systemd integration as example)
1) self­reported status

50. “The matter of logitoring
Best practices:
Logitoring
Architecture­driven
logitoring lifecycle
is events/facts provision
to all infrastructure levels.
There are no “logging” or “monitoring” terms anymore ­
Both are just the functions of the event provision engine”
(erlang zabbix sender as example)
1) self­reported status

51. “The matter of logitoring
Logitoring
Architecture­driven
logitoring lifecycle
is events/facts provision
to all infrastructure levels.
There are no “logging” or “monitoring” terms anymore ­
Both are just the functions of the event provision engine”
Best practices:
(haproxy syslog as example)
1) self­reported status

52. “The matter of logitoring
Architecture­driven
logitoring lifecycle
is events/facts provision
to all infrastructure levels.
There are no “logging” or “monitoring” terms anymore ­
Both are just the functions of the event provision engine”
Best practices:
(exim syslog as example)
1) self­reported status
Logitoring

53. “The matter of logitoring
Architecture­driven
logitoring lifecycle
is events/facts provision
to all infrastructure levels.
There are no “logging” or “monitoring” terms anymore ­
Both are just the functions of the event provision engine”
Best practices:
(Zabbix LLD as example)
2) dynamic items
Logitoring

54. “The matter of logitoring
Architecture­driven
logitoring lifecycle
is events/facts provision
to all infrastructure levels.
There are no “logging” or “monitoring” terms anymore ­
Both are just the functions of the event provision engine”
Best practices:
(Elasticsearch & Kibana4 as example)
2) dynamic items
Logitoring

55. “The matter of logitoring
How we can integrate Archi­schemes in Zabbix?
Architecture­driven
logitoring lifecycle
is events/facts provision
to all infrastructure levels.
There are no “logging” or “monitoring” terms anymore ­
Both are just the functions of the event provision engine”
(maps)
Logitoring

56. “The matter of logitoring
How we can integrate Archi­schemes in Zabbix?
Architecture­driven
logitoring lifecycle
is events/facts provision
to all infrastructure levels.
There are no “logging” or “monitoring” terms anymore ­
Both are just the functions of the event provision engine”
(item/trigger source)
Logitoring

57. “The matter of logitoring
How we can use Archi­schemes as
Architecture­driven
logitoring lifecycle
is events/facts provision
to all infrastructure levels.
There are no “logging” or “monitoring” terms anymore ­
Both are just the functions of the event provision engine”
CMDB/Service Registration ?
Logitoring

58. What I'm speaking about last 20 minutes?
The message

59. “The matter of logitoring
the successful monitoring­like solutuion
We need to cooperate
In order to build up
is events/facts provision
to all infrastructure levels.
There are no “logging” or “monitoring” terms anymore ­
Both are just the functions of the event provision engine”
reflecting our real business value
The message

60. or
the meaning of “logitoring” in architecture­driven logitoring lifecycle
Architecture­driven
logitoring lifecycle
“please, no more another
ugly DevOps logging and monitoring pattern”
Thanks!
[ please relax, take a deep breath
and feel free to speak about :]

61. or
the meaning of “logitoring” in architecture­driven logitoring lifecycle
Architecture­driven
logitoring lifecycle
e.istomin@edss.eeEugene Istomin
IT Architect Cone Center,Tallinn
“please, no more another
ugly DevOps logging and monitoring pattern”
Thanks!