Wikipedia article defines software architect as:
a computer programmer who makes high-level design choices and dictates technical standards, including software coding standards, tools, or platforms...
Given above, your estimates "50% of my time spent... analysing the software logs... 30% fixing other's bugs" put you far far off of what software architect is normally expected to do.
- I would say above makes the title they gave you about
Note that per se, activities like analyzing logs or fixing other's bugs could legitimately occupy part of architect's time - provided that these serve the primary purpose of this role - that is, making high-level design choices and establishing technical standards. Actually, this is the case for any kind of software development / maintenance / testing activities.
For example, if analyzing logs led you to an insight on how to make it easier - by improving design, or tooling, or coding standards - this would be perfectly justifiable effort for an architect. Similarly, it could be completely OK for architect to get their hands dirty fixing particular bug(s) - as long as this would result in specific design / process improvements leading to lower bug rate, etc.
On a little more positive note, your question demonstrates at least one skill that is quite important for architect: ability to classify different kind activities and track efforts spent on these. Consider adding to your "toolbox" complementary skills to summarize your observations and estimates and clearly communicate these, especially up the management ladder. :)